Saya Merancang Sendiri Codec Video Streaming Game Supercepat PyroWave

• Streaming game menuntut latensi yang sangat rendah sebagai syarat mutlak
• PyroWave mencapai kecepatan ekstrem dengan menghilangkan prediksi gerak dan entropy coding
• Pendekatan ini berbasis Discrete Wavelet Transform (DWT), berbeda dari codec DCT konvensional
• Encoding/decoding di GPU sangat cepat berkat pemrosesan paralel berbasis blok 32×32 dan implementasi rate control yang cepat
• Evaluasi kualitas menunjukkan hasil yang memadai dalam situasi tertentu bahkan saat dibandingkan dengan H.264/HEVC/AV1

---

Kebutuhan latensi ultra-rendah pada streaming game dan keterbatasan pendekatan yang ada

• Seiring meningkatnya permintaan untuk streaming gameplay, transmisi real-time melalui jaringan dari satu perangkat ke perangkat lain menjadi semakin penting
• Latensi yang terakumulasi di setiap tahap, mulai dari DMA, rendering, encoding, transmisi, decoding, hingga output layar, sangat memengaruhi pengalaman secara keseluruhan
• Solusi tradisional adalah menggunakan codec video dengan akselerasi GPU seperti H.264, HEVC, dan AV1
• Namun dalam streaming, teknik kompresi tinggi seperti B-frame tidak bisa digunakan, sehingga batasan latensi dan bitrate menjadi lebih berat

Filosofi desain: menghapus prediksi gerak dan entropy coding

Menghapus prediksi gerak – pendekatan Intra-Only

• Prediksi gerak pada codec video konvensional dihapus sehingga setiap frame diperlakukan secara terpisah
• Akibatnya bitrate meningkat, tetapi ada keunggulan dalam ketahanan terhadap error, kesederhanaan, dan konsistensi kualitas
• Pendekatan Intra-only juga sudah pernah digunakan di bidang seperti digital cinema
• Karena itu pendekatan ini kurang cocok untuk streaming internet, tetapi dapat memberi hasil baik di lingkungan berbandwidth tinggi seperti LAN

Menghapus entropy coding

• Entropy coding dikeluarkan sepenuhnya karena tidak cocok untuk pemrosesan paralel di GPU
• Wilayah yang sebelumnya hanya ada untuk ASIC khusus atau perangkat spesial diwujudkan dengan pendekatan berbasis software
• Ini membuka ranah codec ultra-rendah-latensi yang tidak ada di FFmpeg

Pendekatan baru dengan memanfaatkan transformasi wavelet (DWT)

• Alih-alih DCT yang digunakan codec konvensional, pendekatan ini mengadopsi Discrete Wavelet Transform (DWT)
• Transformasi wavelet mirip dengan struktur mip-map yang akrab bagi programmer grafis
• Gambar dipisahkan ke dalam beberapa band, lalu kuantisasi diterapkan pada tiap band
• Band frekuensi tinggi dikuantisasi lebih kuat untuk memaksimalkan karakteristik visual
• Proses ini juga terkait dengan rate control

Artefak khas dan keterbatasan codec berbasis wavelet

• Alih-alih blocking artifact seperti pada JPEG, wavelet terutama menimbulkan blur atau ringing
• Efek ini bisa jadi bukan masalah besar dalam praktik karena bertumpuk dengan blur akibat TAA pada game modern

Packing bitstream berkecepatan tinggi dan paralelisasi

• Blok koefisien 32×32 diproses secara independen sehingga saat terjadi packet loss, dampaknya dibatasi pada blur lokal saja
• Susunan sub-blok 8×8 dan 4×2 mengoptimalkan pemrosesan paralel per unit GPU workgroup
• Bitplane encoding digunakan, tetapi data bit mentah disimpan tanpa entropy coding yang kompleks
• Pendekatan ramah GPU seperti penyimpanan SSBO 8-bit memaksimalkan efisiensi memori dan kecepatan pemrosesan

Rate control yang akurat dan cepat

• Berbeda dari pendekatan entropy coding konvensional, jumlah bit yang dihilangkan untuk tiap blok diukur dan disimpan berulang kali agar rasio dapat disesuaikan dengan tepat
• Secara global, rentang rate-distortion optimal dihitung untuk mematuhi CBR secara ketat
• Keunggulan codec keluarga wavelet berupa penghentian awal per bitplane juga berhasil dicapai melalui software

Kinerja dan efisiensi nyata

• Pada 1080p 4:2:0, encoding/decoding selesai dalam 0.13ms di GPU RX 9070 XT
• Tiap tahap pemrosesan seperti DWT dan kuantisasi memanfaatkan optimisasi FP16 untuk menyeimbangkan trade-off antara kualitas dan kecepatan
• Untuk video 4K, hasil eksperimen menunjukkan bahwa mengompresi di GPU lalu mentransfernya lebih cepat daripada kecepatan transfer PCI-e
• Kecepatan yang dicapai bahkan lebih dari 10 kali lebih cepat dibanding codec hardware khusus

Evaluasi kualitas dan perbandingan dengan codec lain

• Kelompok pembanding: encoder GPU FFmpeg (H.264/HEVC/AV1) dalam mode Intra-only, CBR, dan latensi minimum
• Dalam kondisi 200Mbps dan 60fps, artefak kompresi pada PyroWave hampir tidak bisa dibedakan secara visual
• Untuk berbagai adegan game, hasil yang memadai juga diperoleh melalui metrik kualitas objektif seperti VMAF, SSIM, dan PSNR
• Beberapa metrik tertentu (seperti VMAF) menilai PyroWave agak terlalu baik, sedangkan PSNR dan sejenisnya memperlihatkan pengaruh presisi internal
• Meski ada blur atau artefak berkualitas rendah pada gambar, hal itu bukan masalah besar untuk penggunaan nyata mengingat visual game modern dan tujuan pemakaiannya

Kesimpulan

• PyroWave menghadirkan alternatif inovatif untuk streaming game lokal yang membutuhkan latensi sangat rendah dan pemrosesan berkecepatan tinggi
• Codec ini selaras dengan arsitektur GPU modern dan dioptimalkan untuk pemrosesan paralel serta kontrol CBR
• Meski merupakan proyek pribadi, tingkat kepuasannya tinggi sebagai solusi streaming supercepat DIY

[GN⁺]

Komentar Hacker News

• Membahas VC-2, codec ultra-rendah-latensi berbasis wavelet intra-only yang dikembangkan BBC. Codec ini bisa digunakan tanpa royalti, dan saat ini baru ada implementasi berbasis CPU di ffmpeg dan repositori resmi BBC. Ia berencana membuat versi berakselerasi CUDA sebagai tesis masternya. Implementasi Vulkan yang dikerjakan pada GSoC tahun lalu masih belum memuaskan. Ia merekomendasikan agar orang-orang benar-benar melihat codec ini

  • Bertanya apakah bisa dijelaskan lebih detail mengapa implementasi Vulkan kurang memadai. Bukan berniat menyalahkan, benar-benar penasaran
  • Bertanya tentang pengalaman perbedaan kualitas gambar antara VC-2 dan JPEG XS. Katanya secara umum JPEG XS memberi kualitas visual lebih tinggi, tetapi penasaran bagaimana rasanya dalam penggunaan nyata

• Tulisan ini adalah contoh yang sangat bagus dalam menjelaskan toleransi distorsi dan trade-off yang cocok dengan karakteristik sinyal. Bahkan jika posisinya bukan merancang codec melainkan memilihnya, mengikuti proses ini tetap bisa menghasilkan hasil yang baik. Jika tertarik pada bidang yang mengutamakan latensi sangat rendah, laporan VSF yang merangkum karakteristik berbagai codec alternatif (tautan) akan berguna

• Saya hampir tidak tahu apa-apa tentang encoding video, tetapi saya pikir jika encoder bisa bekerja sama meski sedikit dengan game engine, ada banyak pendekatan praktis yang terlewat dalam streaming videogame. Misalnya, kebanyakan rendering engine sudah punya buffer prediksi gerakan untuk kegunaannya sendiri, dan itu bisa dipakai gratis juga untuk encoding. Tapi sayangnya sepertinya ada paten yang menghambat inovasi semacam ini sehingga mungkin sulit diwujudkan

  • Menekankan bahwa “motion vector” di H.264 hanyalah teknik kompresi gambar berbasis bit, berbeda dari motion vector yang dipakai dalam game 3D sungguhan. Motion vector di game 3D adalah perubahan posisi objek dalam ruang 3D, sedangkan di H.264 caranya adalah menyalin blok piksel dari frame sebelumnya yang dipilih secara arbitrer lalu mengodekan perbedaannya dengan cara ala JPEG. Menjelaskan bahwa akibat penyalinan blok ini, jika bandwidth kurang maka video H.264 akan terlihat rusak menjadi potongan kotak-kotak
  • Mengambil contoh game FPS dengan latensi jaringan 2 frame: jika game engine menyediakan UI dan tampilan dunia 3D sebagai framebuffer terpisah, maka begitu klien menerima input mouse, sisi klien bisa lebih dulu menggeser hanya tampilan dunia pada frame sebelumnya yang diterima dari server. Game VR sudah mengompensasi latensi input dengan cara seperti ini. Tidak sempurna, tetapi perbedaannya besar, dan paralaks pun sampai batas tertentu bisa disimulasikan jika memanfaatkan depth map
  • Seperti encoding video berbasis sensor, informasi akselerometer atau kompas digital ponsel dapat dimanfaatkan untuk memberi petunjuk encoding (tautan). Untuk game 2D, motion vector latar belakang dan objek foreground besar bisa diberikan dengan akurat. Elemen 2D seperti overlay, HUD, papan skor, dan subtitle dapat dikirim dengan metode kompresi terpisah untuk meningkatkan ketajaman piksel. Menyatakan terkejut karena di HN banyak yang skeptis terhadap ide seperti ini
  • Saya juga selalu penasaran soal bagian ini. Saya rasa klien bisa menangani sedikit compositing sendiri. Misalnya, latar belakang dan foreground dirender dengan siklus berbeda, atau HUD memakai codec yang jelas berdasarkan prioritas. Saya selalu heran Stadia, meski punya game buatan sendiri, tetap memakai pendekatan streaming video biasa. Mungkin mereka sudah mencoba berbagai hal, tetapi tidak mendapat keuntungan yang cukup dibanding codec video yang ada
  • Untuk game sprite 2D, encoder bisa dengan mudah diberi motion vector yang sangat akurat. Untuk game rendering 3D, saya tidak yakin apakah mengubah motion vector untuk objek 3D agar cocok dengan encoding 2D benar-benar akan membantu secara praktis

• Mengusulkan pendekatan memakai LLM (large language model) untuk merangkum situasi dalam game menjadi beberapa kalimat di setiap frame lalu mengirimkannya lewat jaringan, dan LLM di sisi penerima merekonstruksi frame dari teks itu. Menyebut bahwa ini sulit untuk real-time dan kehilangan informasinya besar, tetapi rasio kompresinya luar biasa dan sesuai tren terbaru

  • Sebagai contoh frame 1, bisa dideskripsikan seperti: “Anda berdiri di padang sebelah barat, dan pintu depan rumah putih tertutup papan. Ada kotak surat kecil di sini”
  • Menambahkan bahwa jika penjelasan seperti ini dikirim dengan blockchain, bisa juga dibuat catatan yang tidak dapat diubah
  • Berharap suatu hari nanti akan datang zaman ketika game dijalankan langsung di komputer masing-masing pengguna
  • Menyatakan ide di atas menarik

• Metode codec ini hampir sama persis dengan yang hendak saya pakai dalam proyek riset. Sebagai referensi, untuk proyek komersial, karena isu patent pool, standar berbayar JPEG-XS (tautan1, tautan2) yang juga mengklaim latensi ultra-rendah mungkin bisa menjadi pilihan yang lebih aman

  • JPEG-XS kuat dalam latensi ultra-rendah tetapi memakai bandwidth lebih besar. Kami menggunakannya untuk streaming gambar real-time pada post-production film/TV (tautan kasus). Kami memakai encoder/decoder CUDA dari IntoPIX dan metode transmisi latensi-rendah SRT. Pada jaringan yang nyaman, mencapai total latensi di bawah 16ms sangat memungkinkan. Ada use case dengan beberapa rasio kompresi antara data center dan studio post-production di pusat kota, atau bahkan pada jalur 1GbE antarnegara
  • Menyatakan bahwa patent pool bukan jaring pengaman. Ini seperti harus membayar untuk menyeberangi jembatan paten, tetapi setelah itu jika muncul masalah paten lain, Anda harus membayar lagi

• Membagikan bahwa pendiri VLC sedang mengembangkan protokol streaming ultra-rendah-latensi, beserta wawancara (tautan) dan video demo (tautan)

  • Berdasarkan karier di bidang ini, menekankan bahwa encoder hardware dan H.264 punya latensi yang sangat rendah. NVENC hampir bisa melakukan encoding seketika jika fitur tambahan (prediksi multi-frame, B-frame, dan sebagainya) dimatikan. Menjelaskan bahwa selama menghindari algoritme pemrosesan tingkat lanjut atau metode yang menuntut menunggu beberapa frame, encoding bisa dilakukan dalam <10ms setelah rendering GPU selesai
  • Menyebut bahwa video pada tautan itu saat ini tidak bisa ditonton

• Menyadari bahwa pendekatan CODEC ini berbasis algoritme yang sama seperti HTJ2K (High-Throughput JPEG 2000), dan jika penulis melihatnya, akan menarik bila ia menjelaskan perbedaannya dengan HTJ2K

• Menjelaskan bahwa jika hanya fokus pada streaming jaringan lokal, banyak fitur codec modern sebenarnya tidak diperlukan. Selama bandwidth sekitar 100Mbps tersedia, pemrosesan bisa dibuat cepat dan latensinya juga kecil. Sebagai contoh, codec Microsoft DXT hampir tidak punya fitur codec modern (tanpa entropy encoding, motion compensation, atau deblocking), tetapi dengan rasio kompresi 4~8x dan decoding hardware, ia menguntungkan untuk mengurangi total latensi. Namun ditegaskan bahwa bahkan jika dioptimalkan, display itu sendiri tetap menambah latensi 30~100ms

• Menyampaikan bahwa hasil pengembangannya benar-benar luar biasa, dan berharap suatu hari nanti akan diterapkan ke Moonlight atau proyek serupa

  • Menyatakan bahwa ia juga berpikir sama, dan kalau punya waktu serta kemampuan, ia ingin mencoba langsung menambahkan dukungan codec ini ke Moonlight. Menyebut bahwa saat streaming game seperti Clair Obscure lewat Sunshine/Moonlight di LAN, latensi yang cukup rendah memang sangat dibutuhkan

• Mengutip pendapat bahwa karena codec ini masih tergolong asing dan spesialis, sulit menemukan materi perbandingan dengan codec pesaing, lalu menyatakan penasaran dengan benchmark terhadap H.264/AVC (opsi ffmpeg zero-latency) dan JPEG XS. Juga membagikan contoh perintah ffmpeg beserta parameter encoding yang rinci