Deep Dive into Multimedia Systems & WebRTC — from GPU frame capture to browser display in under 100ms.بررسی عمیق سیستمهای مالتیمدیا و WebRTC — از کپچر فریم GPU تا نمایش در مرورگر در زیر ۱۰۰ میلیثانیه.
14Sectionsبخش~45 minAdvanced
02 / 14
Overviewنمای کلی
The Pipelineپایپلاین
Data journey from GPU render to display. We focus on the three middle stages.مسیر داده از رندر GPU تا نمایش. تمرکز ما روی سه مرحله وسطی است.
🖥️GPU Renderرندر GPU
→
📷Frame Captureکپچر فریم
→
🗜️Encoder▲ FOCUS
→
🌐Network▲ FOCUS
→
📦Decoder▲ FOCUS
→
📺Display
THIS PRESENTATION: ENCODER · NETWORK · DECODERموضوع این ارائه: ENCODER · NETWORK · DECODER
03 / 14
Performanceکارایی
Latency: The Silent Killerلیتنسی: قاتل پنهان
Total end-to-end budget: 100ms. Beyond this, gameplay feels "laggy".بودجه زمانی کل: ۱۰۰ms. فراتر از این، بازی «کند» احساس میشود.
0ms ─────────────────────────── 100ms
Network RTTشبکه
Encode
Decode
Display
Misc
Network RTT (~40ms) — biggest variable, depends on edge node proximityتأخیر شبکه (~۴۰ms) — بزرگترین متغیر، وابسته به فاصله از Edge Node
Encoding Time (~20ms) — hardware encoder (NVENC/AMF) vs software x264زمان انکود (~۲۰ms) — انکودر سختافزاری (NVENC/AMF) در مقابل نرمافزاری x264
Decode Time (~15ms) — hardware decode on client GPU/SoCزمان دیکود (~۱۵ms) — دیکود سختافزاری روی GPU/SoC کلاینت
Display Pipeline (~15ms) — vsync, frame buffer, panel responseپایپلاین نمایش (~۱۵ms) — vsync، فریمبافر، زمان پاسخ پنل
⚡ Key Insightنکته کلیدی: Network latency dominates the budget. This is why cloud gaming requires Edge Computing — servers physically close to users. Encoding must use hardware acceleration (NVENC, Intel QuickSync) to stay under 20ms. تأخیر شبکه بیشترین سهم را دارد. به همین دلیل Cloud Gaming به Edge Computing نیاز دارد — سرورهایی که فیزیکی نزدیک کاربر باشند. انکودینگ حتماً باید از شتابدهنده سختافزاری (NVENC, QuickSync) استفاده کند.
04 / 14
Video Compressionفشردهسازی ویدئو
Video Compression Standardsاستانداردهای فشردهسازی ویدئو
Choosing the right codec: a tradeoff between efficiency, licensing cost, and encode speed.انتخاب کدک مناسب: توازنی بین بازدهی، هزینه لایسنس و سرعت انکود.
Codec
Licenseلایسنس
Compressionفشردهسازی
Encode Speedسرعت انکود
HW Supportپشتیبانی HW
Used Inکاربرد
H.264 AVC / 2003
Proprietary
Baseline
⚡⚡⚡ Very Fastخیلی سریع
Universalهمهجا
Stadia, legacy
H.265 HEVC / 2013
Proprietary
+40% vs H.264
⚡⚡ Fast (HW)سریع (HW)
Modern GPUsGPUهای جدید
GFN, PS Now
AV1 AOMedia / 2018
Open Source
+50% vs H.265
⚡ Slow (SW)کند (SW) ⚡⚡ HW
RTX 4000+, M3+
Xbox Cloud, future
Why AV1? Zero royalties (critical for large-scale cloud deployment), 50% better compression than H.265, browser-native via WebCodecs API. Catch: software encoding is 10–20× slower — hardware encoders (NVENC AV1 on RTX 4000) are mandatory. بدون هزینه لایسنس (حیاتی برای استقرار در مقیاس بزرگ)، ۵۰٪ فشردهسازی بهتر از H.265، پشتیبانی مرورگر از طریق WebCodecs API. اما: انکود نرمافزاری ۱۰ تا ۲۰ برابر کندتر است — انکودر سختافزاری الزامی است.
05 / 14
Compression Internalsدرون کدک
Intra vs Inter-frame Compressionفشردهسازی Intra در برابر Inter
GOP (Group of Pictures) structure defines how frames reference each other — critical for latency.ساختار GOP تعریف میکند که فریمها چگونه به یکدیگر ارجاع میدهند — تأثیر مستقیم بر لیتنسی دارد.
I
I-Frame Full image ~100KBتصویر کامل ~۱۰۰KB
→
P
P-Frame Delta from I ~8KBتغییر از I ~۸KB
→
P
P-Frame Delta from P ~8KBتغییر از P ~۸KB
→
B
B-Frame BLOCKED
→
B
B-Frame BLOCKED
→
I
I-Frame Next GOPGOP بعدی
🚫 No B-Frames in Cloud GamingB-Frame در Cloud Gaming ممنوع: B-Frames need to "look ahead" into future frames before encoding the current one. This introduces mandatory delay of several frame periods (16–50ms at 60fps). In cloud gaming, every millisecond counts — B-frames are disabled entirely. We accept slightly larger files in exchange for zero lookahead latency. B-Frame باید به فریمهای آینده «نگاه کند» قبل از اینکه فریم کنونی را انکود کند. این یعنی تأخیر اجباری چند پریود فریمی (۱۶ تا ۵۰ms در 60fps). در Cloud Gaming هر میلیثانیه اهمیت دارد — B-Frame به طور کامل غیرفعال میشود. حجم کمی بالاتر، اما لیتنسی صفر.
06 / 14
Color Scienceعلم رنگ
Color Space: RGB → YUVفضای رنگ: RGB به YUV
Why convert to YUV? Human vision is far more sensitive to brightness than color.چرا به YUV تبدیل کنیم؟ چشم انسان به روشنایی بسیار حساستر از رنگ است.
RGB — Display Spaceفضای نمایش
R
G
B
3 equal channels. Each pixel stores full Red, Green, Blue values. Display-native but inefficient — all channels treated with equal importance. A 1080p frame = 1920×1080×3 = ~6 MB uncompressed.۳ کانال برابر. هر پیکسل مقادیر کامل Red، Green و Blue را ذخیره میکند. بومی نمایشگر اما ناکارآمد — همه کانالها با اهمیت برابر. یک فریم 1080p = 1920×1080×3 = ~۶ مگابایت بدون فشردهسازی.
YUV — Perceptual Spaceفضای ادراکی
Y
U
V
Y = Luma (brightness). U, V = Chroma (color difference). Human eyes have ~4× more luminance receptors than color receptors. YUV lets us keep full luma resolution while downsampling color channels — the eye barely notices.Y = روشنایی (Luma). U, V = رنگ (Chroma). چشم انسان ~۴ برابر گیرنده روشنایی بیشتر از گیرنده رنگ دارد. YUV به ما اجازه میدهد رزولوشن کامل روشنایی را حفظ کنیم و کانالهای رنگ را کاهش دهیم.
Y = 0.299R + 0.587G + 0.114B | U = -0.147R - 0.289G + 0.436B | V = 0.615R - 0.515G - 0.100B
07 / 14
Chroma Subsampling
4:4:4 vs 4:2:0
Reducing color sample resolution — one of the most impactful compression steps, with a visible trade-off in text rendering.کاهش رزولوشن نمونهبرداری رنگ — یکی از مؤثرترین مراحل فشردهسازی، با یک تبعات قابل مشاهده در رندر متن.
4:4:4 — Full ChromaChroma کامل
Every pixel has its own full U and V chroma sample. Bandwidth = Y+U+V = 3× luma.هر پیکسل نمونه کامل U و V خود را دارد. پهنای باند = Y+U+V = ۳ برابر Luma.
RED TEXT4:4:4 — SHARP EDGES
4:2:0 — Chroma Halved BothChroma نصف در هر دو محور
Each 2×2 block shares a single chroma sample. Bandwidth = 1.5× luma. 50% bandwidth reduction. Used by H.264/H.265/AV1.هر بلوک ۲×۲ یک نمونه Chroma مشترک دارد. پهنای باند = ۱.۵ برابر Luma. کاهش ۵۰٪ پهنای باند. استفاده در H.264/H.265/AV1.
RED TEXT4:2:0 — CHROMA FRINGING ON EDGES
4:2:2 — Horizontal Halfنصف افقی
Chroma sampled every other pixel horizontally only. Bandwidth = 2× luma. Compromise used in professional broadcast — better text rendering than 4:2:0.Chroma فقط یکدرمیان به صورت افقی نمونهبرداری میشود. پهنای باند = ۲ برابر Luma. کمپرومایز حرفهای — رندر متن بهتر از 4:2:0.
Cloud gaming typically uses 4:2:0 for bandwidth savings, with optional 4:4:4 mode for UI-heavy titles.Cloud Gaming معمولاً از 4:2:0 برای صرفهجویی در پهنای باند استفاده میکند، با حالت اختیاری 4:4:4 برای بازیهای پر از UI.
08 / 14
Transport Layerلایه انتقال
WebRTC: The Real-time Engineموتور بلادرنگ
WebRTC enables sub-100ms peer-to-peer media streaming directly in browsers — no plugins, no proprietary stack.WebRTC استریم رسانهای Peer-to-Peer زیر ۱۰۰ms را مستقیم در مرورگر ممکن میکند — بدون پلاگین، بدون Stack اختصاصی.
🖥️
Cloud Server GPU Nodeسرور ابری · GPU Node
ENCODER
UDPICEDTLSSRTPSCTP
P2P · ENCRYPTED · NAT TRAVERSAL
🌐
Browser / Native Appمرورگر / اپلیکیشن
DECODER
UDP
Connectionless, no guaranteed delivery. Ideal for real-time — a lost frame is better than a delayed one.بدون اتصال، بدون تضمین تحویل. ایدهآل برای بلادرنگ — یک فریم گمشده بهتر از یک فریم با تأخیر است.
ICE / STUN / TURN
NAT traversal — finds the fastest path between server and client through firewalls and carrier-grade NAT.عبور از NAT — سریعترین مسیر بین سرور و کلاینت را از میان فایروال و NAT اپراتوری پیدا میکند.
DTLS + SRTP
Mandatory encryption for all WebRTC media. TLS semantics over UDP — no unencrypted streams allowed.رمزنگاری اجباری برای تمام رسانه WebRTC. معناشناسی TLS روی UDP — هیچ استریم رمزنشدهای مجاز نیست.
09 / 14
Transport Protocolپروتکل انتقال
UDP vs TCP in GamingUDP در برابر TCP در گیمینگ
TCP's reliability guarantee — Head-of-Line Blocking — is catastrophic for real-time gaming.تضمین قابلیت اطمینان TCP — Head-of-Line Blocking — برای بازی بلادرنگ فاجعهبار است.
TCP — Reliable, Orderedقابل اعتماد، مرتب
Packets 1,2,3... Packet 3 lost:بستههای ۱،۲،۳... بسته ۳ گم شد:
1
2
✕3
4
5
6
7
⏳ ALL WAITING FOR RETRANSMIT OF #3همه منتظر ارسال مجدد #۳
Packets 4–7 are buffered even though they arrived. The stream stalls waiting for #3. In a 60fps game, this causes a visible freeze of 100–300ms — unacceptable.بستههای ۴ تا ۷ بافر میشوند حتی اگر رسیده باشند. استریم منجمد میشود تا #۳ دوباره بیاید. در بازی 60fps این یک freeze قابل مشاهده ۱۰۰ تا ۳۰۰ms ایجاد میکند.
UDP — Best-effort, No Orderبهترین تلاش، بدون ترتیب
Same scenario. Packet 3 lost:همان سناریو. بسته ۳ گم شد:
1
2
✕3
4
5
6
7
✓ STREAM CONTINUES — #3 IS DROPPEDاستریم ادامه دارد — #۳ رها میشود
Packets 4–7 continue immediately. Frame #3 is simply dropped — the decoder uses the previous frame or interpolates. A single dropped frame is imperceptible; a 300ms stall is not. WebRTC uses UDP exclusively for media.بستههای ۴ تا ۷ فوراً ادامه مییابند. فریم #۳ رها میشود — دیکودر از فریم قبلی استفاده میکند یا interpolate میکند. یک فریم رها شده نامحسوس است؛ یک freeze 300ms نه.
10 / 14
Input Handlingپردازش ورودی
WebRTC Data Channels
Controller inputs travel on a separate low-latency channel alongside the video stream — using SCTP over DTLS over UDP.ورودیهای کنترلر روی یک کانال جداگانه کملیتنسی در کنار استریم ویدئو ارسال میشوند — از طریق SCTP روی DTLS روی UDP.
1
Player presses buttonبازیکن دکمه را فشار میدهد — Input event captured at native app or browser. Timestamp added (monotonic clock). Event size: ~16 bytes.رویداد ورودی در اپ یا مرورگر کپچر میشود. Timestamp اضافه میشود (ساعت یکنواخت). اندازه رویداد: ~۱۶ بایت.
2
DataChannel.send() — ~1ms localSent via WebRTC Data Channel (SCTP). Can be ordered+reliable (critical inputs) or unordered+unreliable (high-frequency analog sticks).از طریق WebRTC Data Channel (SCTP) ارسال میشود. میتواند مرتب+قابل اعتماد (ورودیهای حیاتی) یا نامرتب+غیرقابل اعتماد (آنالوگاستیکهای پرسرعت) باشد.
3
Server receives inputسرور ورودی را دریافت میکند — RTT/2 delayCloud game server dequeues input, applies to game simulation. Input prediction handles out-of-order arrival.سرور بازی ابری ورودی را از صف خارج کرده و به شبیهسازی بازی اعمال میکند. پیشبینی ورودی برای مدیریت ورود خارج از ترتیب.
4
Frame rendered with input appliedفریم با ورودی اعمالشده رندر میشود — GPU renders game state reflecting the button press. Total input-to-pixel: RTT + encode + decode ≈ 60–80ms on good edge.GPU حالت بازی منعکسکننده فشار دکمه را رندر میکند. کل زمان ورودی تا پیکسل: RTT + encode + decode ≈ ۶۰ تا ۸۰ms روی edge خوب.
5
Input Prediction (client-side)پیشبینی ورودی (سمت کلاینت) — Advanced clients simulate predicted game state locally while waiting for authoritative server frame. Used by NVIDIA GFN and Xbox Cloud Gaming.کلاینتهای پیشرفته حالت پیشبینیشده بازی را به صورت محلی شبیهسازی میکنند در حالی که منتظر فریم معتبر سرور هستند. استفاده در NVIDIA GFN و Xbox Cloud.
11 / 14
Client-side Decodingدیکود سمت کلاینت
Jitter Buffer & Smooth PlaybackJitter Buffer و پخش روان
Network jitter is the variance in packet arrival time. Without compensation, it causes frame tears and stalls.Jitter شبکه یعنی نوسان در زمان ورود بستهها. بدون جبران، باعث پارگی و توقف فریم میشود.
Frames rendered as they arrive — bursts cause dropped frames, gaps cause freezes.فریمها به محض ورود رندر میشوند — انفجارها باعث drop فریم، فاصلهها باعث freeze میشوند.
ADAPTIVE JITTER BUFFERJITTER BUFFER تطبیقی
Buffer absorbs variance. Size adapts dynamically. Tradeoff: slightly higher minimum latency (+5–20ms).بافر نوسان را جذب میکند. اندازه به صورت پویا تنظیم میشود. معامله: کمی افزایش حداقل لیتنسی (+۵ تا ۲۰ms).
12 / 14
Network Infrastructureزیرساخت شبکه
CDN vs Edge ComputingCDN و Edge در کلاد گیمینگ
Why traditional CDNs don't work for gaming, and why Edge nodes are the true enablers of the cloud gaming revolution.چرا CDN سنتی برای بازی کار نمیکند و چرا Edge Nodes کلید اصلی انقلاب کلاد گیمینگ هستند.
Traditional CDN (Web/VOD)شبکه توزیع محتوا (CDN کلاسیک)
Used for caching static assets (images, JS, recorded videos like Netflix/YouTube). Content is created once, distributed globally, and fetched locally by the user. Cannot cache a live, interactive game stream.برای کش کردن فایلهای ثابت (عکس، ویدیوهای ضبط شده مثل نتفلیکس) استفاده میشود. محتوا یک بار ساخته و همهجا توزیع میشود. در کلاد گیمینگ چون تصویر لحظهای تولید میشود، کش کردن غیرممکن است.
Instead of caching files, we distribute GPU Compute Power. Servers are placed in local telco datacenters (PoPs) physically close to the user. This reduces network ping (RTT) to under 20ms, making real-time interactive streams feel local.به جای کش کردن فایل، قدرت پردازش گرافیکی (GPU) را توزیع میکنیم. سرورها در دیتاسنترهای مخابراتی نزدیک کاربر مستقر میشوند تا پینگ (RTT) به زیر ۲۰ میلیثانیه برسد و بازی روان اجرا شود.
13 / 14
Futureآینده
The Future: AI & Edge Computingآینده: هوش مصنوعی و Edge Computing
The next frontier of cloud gaming eliminates remaining latency and bandwidth constraints.مرز بعدی Cloud Gaming محدودیتهای باقیمانده لیتنسی و پهنای باند را از بین میبرد.
🧠
Neural Super Sampling
Cloud-side DLSS/FSR: render at 720p on server GPU, run a neural upscaling network to output 4K. Reduces encoding bandwidth by 4× while maintaining visual fidelity. Inference adds ~3ms on dedicated tensor cores.DLSS/FSR سمت ابر: رندر در 720p روی GPU سرور، اجرای شبکه عصبی Upscaling برای خروجی 4K. کاهش ۴ برابری پهنای باند انکود با حفظ کیفیت بصری. استنتاج ~۳ms روی هستههای Tensor اختصاصی.
🔮
Predictive Renderingرندر پیشبینانه
AI predicts player input 1–3 frames ahead based on game state and controller velocity. Pre-renders probable next frames — effectively negative latency perception.هوش مصنوعی ورودی بازیکن را ۱ تا ۳ فریم جلوتر بر اساس حالت بازی و سرعت کنترلر پیشبینی میکند. پیشرندر فریمهای احتمالی بعدی — عملاً لیتنسی منفی از نظر ادراکی.
⚡
AV1 Hardware at Scaleسختافزاری در مقیاس
As AV1 hardware encoders become ubiquitous (Intel Arc, NVIDIA Ada, AMD RDNA3+), the codec will replace H.265 entirely — cutting streaming costs by half while improving quality.با همهجاگیر شدن انکودرهای سختافزاری AV1، این کدک H.265 را کاملاً جایگزین میکند — هزینه استریم نصف، کیفیت بالاتر.
Edge Node Distribution — Target 2027توزیع Edge Node — هدف ۲۰۲۷
14 / 14
Mostafa Tabatabaei
Cloud Gaming • Real-time Systems • Multimedia Architect
