Video encoding pada cloud gaming bekerja dalam kondisi yang cukup ekstrem.
Encoder harus menerima frame baru puluhan kali setiap detik, mengompresnya secepat mungkin, lalu mengirim hasilnya melalui jaringan yang kualitasnya terus berubah.
Jika terlalu mengejar kualitas, latency meningkat. Jika kompresi terlalu agresif, visual menjadi pecah dan sulit dinikmati. Karena itu, Mengoptimalkan Video Encoding tidak bisa dilakukan hanya dengan memilih codec modern.
Developer perlu menghubungkan encoder dengan kondisi jaringan, performa server, kemampuan decoder pemain, serta target frame rate secara real-time.
Mulai dari Target Latency, Bukan Resolusi Maksimum
Kesalahan umum adalah memulai desain streaming dengan pertanyaan, “Bagaimana caranya mempertahankan 4K?”
Pertanyaan yang lebih tepat adalah, “Berapa latency maksimal yang masih nyaman untuk game ini?”
Genre sangat menentukan jawabannya.
Turn-based game relatif toleran terhadap delay. Fighting game, rhythm game, competitive shooter, dan racing jauh lebih sensitif.
Setelah target responsiveness ditentukan, tim baru menentukan resolusi, frame rate, codec, dan bitrate yang realistis.
Sebagai contoh, 60 FPS berarti frame baru tersedia setiap sekitar 16,67 ms. Jika encoder sendiri membutuhkan hampir seluruh waktu tersebut, network dan decoder belum mendapatkan ruang yang cukup dalam latency budget.
Encoding harus menjadi salah satu bagian kecil dari pipeline input-to-photon.
Pertahankan Frame Pacing yang Konsisten
Average encode time tidak selalu menggambarkan pengalaman pemain.
Misalnya, encoder rata-rata menyelesaikan frame dalam 5 ms. Angka itu terlihat bagus.
Tetapi jika sesekali proses melonjak menjadi 30 atau 40 ms, pemain dapat merasakan micro-stutter.
Karena itu, frame pacing perlu dipantau bersamaan dengan throughput encoder.
Ukur median, p95, dan p99 encode latency.
Perubahan visual seperti explosion, smoke, foliage, camera rotation cepat, dan banyak objek kecil sering meningkatkan kompleksitas frame secara tiba-tiba.
Stress test seperti ini penting untuk menemukan konfiguarsi yang terlihat baik pada average tetapi buruk ketika game menjadi ramai.
Gunakan Adaptive Bitrate Berdasarkan Kondisi Nyata
Koneksi internet pemain bukan pipa dengan kapasitas tetap.
Bandwidth bisa berubah karena congestion, Wi-Fi interference, pengguna lain di rumah, atau routing ISP.
Jika encoder terus memaksa 20 Mbps ketika koneksi hanya mampu mengirim 12 Mbps, packet akan mulai mengantre.
Akibatnya, gambar mungkin tetap bagus untuk beberapa saat tetapi latency terus bertambah.
Adaptive bitrate harus merespons throughput, packet loss, jitter, dan round-trip time.
Pada WebRTC, congestion control memang dirancang untuk interactive real-time media dengan perhatian khusus terhadap delay.
IETF menekankan bahwa aplikasi media real-time membutuhkan mekanisme congestion control yang mampu bereaksi terhadap kapasitas jaringan tanpa membangun delay berlebihan.
Selain bitrate, resolusi juga dapat diadaptasikan.
Amazon GameLift Streams Web SDK versi terbaru bahkan menyediakan dynamic resolution yang dapat menyesuaikan resolusi stream berdasarkan kemampuan koneksi pemain.
Turunkan Resolusi sebelum Membiarkan Latency Menumpuk
Banyak sistem mempertahankan resolusi terlalu lama ketika bandwidth menurun.
Padahal pada cloud gaming, gambar sedikit lebih lembut sering lebih baik daripada kontrol yang terlambat.
Jika jaringan tidak mampu mempertahankan 1080p60 pada bitrate yang tersedia, menurunkan resolusi ke 900p atau 720p bisa menjadi pilihan lebih masuk akal.
Amazon GameLift Streams mendukung streaming hingga 1080p 60 FPS pada layanan browsernya dan menyediakan konfigurasi resolusi untuk session streaming.
Prinsipnya bukan selalu memakai resolusi tertinggi.
Pilih kombinasi resolution, bitrate, dan FPS yang bisa dikirim secara konsisten.
Perubahan juga sebaiknya dilakukan bertahap agar pemain tidak melihat gambar terus melompat antara tajam dan buram.
Cocokkan Codec dengan Perangkat Pemain
Codec modern memang menarik karena bisa menghasilkan kualitas lebih tinggi pada bandwidth lebih rendah.
Namun perangkat pemain tetap menjadi faktor besar.
Sebelum memilih AV1 atau HEVC sebagai default, periksa apakah target device mempunyai hardware decoding yang memadai.
Software decoding dapat menggunakan CPU lebih besar dan meningkatkan decode time.
H.264 masih menjadi pilihan aman untuk kompatibilitas luas. Amazon GameLift Streams, misalnya, menggunakan WebRTC dan mensyaratkan dukungan AVC/H.264 pada browser client yang kompatibel.
Di sisi server, NVIDIA NVENC mendukung H.264, HEVC, dan AV1 pada hardware yang memenuhi syarat.
Strategi praktisnya adalah melakukan codec negotiation.
Gunakan codec lebih efisien ketika encoder dan decoder sama-sama mendukungnya secara hardware, lalu gunakan fallback yang lebih kompatibel untuk perangkat lain.
Hindari Queue Panjang di Encoder
Salah satu tujuan utama pipeline real-time adalah menjaga frame tetap “segar”.
Jika encoder mengantre lima frame sebelum mengirimnya, gambar yang diterima pemain sebenarnya sudah tertinggal beberapa frame dari kondisi game server.
Pada 60 FPS, antrean lima frame sendiri sudah mewakili lebih dari 80 ms waktu permainan.
Karena itu, pipeline sebaiknya memiliki prinsip latest frame matters.
Untuk aplikasi interaktif, frame lama sering kehilangan nilai ketika frame terbaru sudah tersedia.
Dokumentasi NVENC merekomendasikan very low VBV buffer untuk game streaming, termasuk konfigurasi setara sekitar satu frame.
Ini berbeda dengan video streaming tradisional yang bisa menggunakan buffer jauh lebih besar untuk mengejar kualitas dan kestabilan.
Atur GOP untuk Menghindari Lonjakan Bandwidth
GOP atau Group of Pictures mengatur hubungan antara I-frame, P-frame, dan B-frame.
GOP yang tidak sesuai dapat menciptakan pola bitrate yang buruk untuk cloud gaming.
Full I-frame biasanya jauh lebih besar daripada predicted frame. Jika dikirim terlalu sering, jaringan dapat menerima spike besar.
NVIDIA merekomendasikan GOP sangat panjang untuk low-latency game streaming serta menyediakan intra refresh sebagai opsi untuk error recovery.
Intra refresh menyebarkan pembaruan intra-coded secara bertahap sehingga beban tidak terkumpul pada satu frame besar.
Namun kondisi packet loss juga harus diperhatikan.
GOP panjang tanpa mekanisme recovery yang tepat bisa membuat corruption bertahan lebih lama jika reference frame hilang.
Karena itu, desain GOP harus mempertimbangkan jaringan nyata, bukan hanya efisiensi codec.
Gunakan Rate Control yang Responsif
Rate control menentukan berapa banyak bit yang dialokasikan encoder untuk setiap frame.
Untuk use case low-latency, NVIDIA merekomendasikan CBR bersama low-latency atau ultra-low-latency tuning.
CBR membantu menjaga bandwidth lebih predictable, sesuatu yang penting untuk interactive streaming.
Namun implementasi tetap membutuhkan feedback loop.
Jika jaringan mengalami congestion, target bitrate harus dapat diturunkan. Jika kondisi membaik selama beberapa detik, kualitas bisa dinaikkan perlahan.
Hindari naik terlalu agresif.
Bitrate yang terus melonjak naik-turun dapat menghasilkan kualitas visual yang tidak konsisten sekaligus memicu congestion baru.
Stabilitas sering lebih penting daripada mengejar bitrate maksimum setiap saat.
Profile Encoder Bersamaan dengan GPU Rendering
Encoding tidak boleh dianalisis secara terpisah dari game.
Server yang menjalankan game mungkin memiliki GPU utilization tinggi ketika scene berat. Pada waktu yang sama, encoder tetap harus menghasilkan video tanpa menambah delay.
Walaupun NVENC merupakan hardware encoder khusus, sistem secara keseluruhan tetap memiliki batas resource, memory bandwidth, dan jumlah session yang dapat ditangani.
NVIDIA menyediakan dokumentasi NVENC untuk membantu developer memahami capabilities serta performa encoder pada GPU yang digunakan.
Lakukan benchmark dengan jumlah session sesuai target produksi.
Satu stream bisa berjalan mulus, tetapi 20 session pada server yang sama dapat menghasilkan kondisi berbeda.
Density testing harus memeriksa encode time, GPU usage, VRAM, memory bandwidth, dropped frame, dan konsitensi frame pacing.
Gunakan Telemetry untuk Menentukan Penyebab Masalah
Keluhan “stream patah-patah” bisa berasal dari banyak tempat.
Encoder mungkin lambat. Network bisa kehilangan packet. Decoder client bisa kewalahan. Game server sendiri mungkin gagal mempertahankan FPS.
Karena itu, log beberapa tahapan secara terpisah.
Catat render time, encode time, bitrate, resolution, codec, frame queue, RTT, jitter, packet loss, decode time, dan frame displayed.
Ketika p95 latency meningkat, telemetry membantu mencari korelasi.
Misalnya, RTT stabil tetapi encode time melonjak. Fokus optimisasi ada pada server.
Jika encode tetap 4 ms tetapi jitter meningkat bersamaan dengan dropped frame, network path lebih patut dicurigai.
Tanpa telemetry, tim hanya melakukan tebakan.
Buat Quality Ladder yang Fleksibel
Satu konfigurasi encoding tidak akan cocok untuk seluruh pemain.
Buat beberapa quality tier, misalnya resolusi dan bitrate untuk jaringan rendah, menengah, dan tinggi.
Tetapi jangan membuat tier hanya berdasarkan bandwidth mentah.
Perhitungkan decoder capability, ukuran layar, refresh rate, dan jenis koneksi.
Smartphone 6 inci mungkin tidak mendapatkan manfaat besar dari bitrate 4K seperti televisi besar.
Sebaliknya, monitor 120 Hz untuk competitive gaming mungkin lebih diuntungkan oleh frame rate tinggi daripada tambahan resolusi.
Quality ladder yang pintar berusaha mengalokasikan bandwidth pada aspek yang benar-benar terlihat dan dirasakan pemain.
Mengoptimalkan Video Encoding untuk cloud gaming real-time berarti menjaga setiap frame tetap cepat, segar, dan sesuai kondisi jaringan.
Gunakan hardware encoder, adaptive bitrate, buffer kecil, codec yang kompatibel, dan GOP yang tepat. Lalu profile encoder bersama rendering serta network telemetry.
Mulailah dari latency budget, bukan kualitas maksimum, agar pengalaman pemain tetap responsif dalam berbagai kondisi koneksi.