Aşırı hızlı oyun akışı video kodeği PyroWave’i bizzat tasarladım

• Oyun akışı için son derece düşük gecikme vazgeçilmezdir
• PyroWave, hareket kestirimi ve entropi kodlamayı kaldırarak uç düzey hıza ulaşıyor
• Ayrık Dalgacık Dönüşümü (DWT) tabanlı yaklaşımıyla mevcut DCT kodeklerinden ayrışıyor
• 32×32 blok bazlı paralel işleme ve hızlı oran kontrolü sayesinde GPU üzerinde kodlama/kod çözme çok hızlı
• Kalite değerlendirmesinde H.264/HEVC/AV1 gibi seçeneklerle karşılaştırıldığında da belirli senaryolarda yeterli sonuç veriyor

---

Oyun akışında ultra düşük gecikme gereksinimi ve mevcut yöntemlerin sınırları

• Son dönemde oyun akışı talebi arttıkça, ağ üzerinden bir cihazdan diğerine gerçek zamanlı aktarım daha önemli hale geldi
• DMA, render alma, kodlama, iletim, kod çözme ve ekran çıktısına kadar her aşamada biriken gecikme, toplam deneyimi büyük ölçüde etkiliyor
• Geleneksel çözüm, H.264, HEVC, AV1 gibi GPU hızlandırmalı video kodeklerini kullanmak
• Ancak akışta B-frame gibi yüksek sıkıştırma teknikleri kullanılamadığından, gecikme ve bit hızı kısıtları daha da sertleşiyor

Tasarım felsefesi: hareket kestirimi ve entropi kodlamayı kaldırmak

Hareket kestirimini kaldırmak – Intra-Only yaklaşımı

• Mevcut video kodeklerindeki hareket kestirimi kaldırılarak tüm kareler birbirinden bağımsız ele alınıyor
• Bunun sonucu olarak bit hızı artıyor; ancak hata dayanıklılığı, sadelik ve kalite tutarlılığı gibi alanlarda avantaj sağlanıyor
• Dijital sinema gibi alanlarda da Intra-only yaklaşımının kullanım geçmişi bulunuyor
• Bu nedenle internet akışı için pek uygun olmasa da LAN gibi yüksek bant genişlikli ortamlarda iyi sonuç verebiliyor

Entropi kodlamayı kaldırmak

• Entropi kodlama, GPU paralel işleme açısından elverişsiz olduğundan tamamen çıkarılmış
• Daha önce yalnızca ASIC odaklı ya da özel donanımlara özgü görülen bir alan yazılım tabanlı biçimde gerçekleştirilmiş
• FFmpeg’de olmayan ultra düşük gecikmeli kodek alanında yeni bir yaklaşım ortaya koyuyor

Dalgacık dönüşümü (DWT) kullanan yeni yaklaşım

• Mevcut kodeklerin DCT yaklaşımı yerine Ayrık Dalgacık Dönüşümü (DWT) benimsenmiş
• Dalgacık dönüşümü, grafik programcılarının aşina olduğu mip-map yapısına benziyor
• Görüntü birden çok banda ayrılıyor ve her banda ayrı nicemleme uygulanıyor
• Yüksek frekans bantları daha güçlü nicemlenerek görsel özelliklerden azami ölçüde yararlanılıyor
• Bu süreç oran denetimiyle de ilişkilendiriliyor

Dalgacık tabanlı kodeklerin tipik artifaktları ve sınırları

• JPEG’deki blocking artifaktları yerine, dalgacık yaklaşımında daha çok bulanıklık veya ringing görülüyor
• Bu durum, modern oyunlarda TAA kaynaklı bulanıklık etkisiyle örtüştüğünden pratikte büyük bir sorun olmayabilir

Yüksek hızlı bit akışı paketleme ve paralelleştirme

• 32×32 katsayı blokları bağımsız işlendiğinden paket kaybı durumunda etki yerel bulanıklıkla sınırlı kalıyor
• 8×8 ve 4×2 alt blok yapılarıyla GPU workgroup düzeyinde paralel işleme optimize ediliyor
• Bitplane kodlama kullanılıyor, ancak karmaşık entropi kodlama olmadan ham bit verisi saklanıyor
• SSBO 8-bit depolama gibi GPU dostu yöntemlerle bellek verimliliği ve işlem hızı en üst düzeye çıkarılıyor

Doğru ve hızlı oran kontrolü

• Geleneksel entropi kodlama yöntemlerinden farklı olarak, her blok için atlanacak bit sayısı yinelemeli biçimde ölçülüp saklanarak uygun oran ayarlanıyor
• Küresel ölçekte en uygun oran-bozulma aralığı hesaplanarak CBR sıkı biçimde korunuyor
• Dalgacık türü kodeklerin güçlü yanı olan bitplane bazlı erken durdurma, yazılımda da başarılmış

Pratik performans ve verimlilik

• 1080p 4:2:0 temelinde RX 9070 XT GPU üzerinde kodlama/kod çözme 0.13 ms’de tamamlanıyor
• DWT, nicemleme ve diğer işlem aşamalarında FP16 optimizasyonları kullanılarak kalite-hız trade-off’u ayarlanabiliyor
• 4K videoda da PCI-e aktarım hızından ziyade GPU’da sıkıştırıp sonra aktarmanın daha hızlı olduğu deneysel olarak doğrulanmış
• Özel donanım kodeklerinden bile 10 kata kadar daha yüksek hız elde edilebiliyor

Kalite değerlendirmesi ve diğer kodeklerle karşılaştırma

• Karşılaştırma grubu: FFmpeg GPU kodlayıcılarında (H.264/HEVC/AV1) Intra-only, CBR ve minimum gecikme modu
• PyroWave, 200Mbps ve 60fps koşullarında gözle bakıldığında sıkıştırma artifaktlarının neredeyse ayırt edilemediği bir sonuç veriyor
• Çeşitli oyun sahnelerinde VMAF, SSIM, PSNR gibi nesnel kalite metrikleriyle de yeterli sonuçlar elde edilmiş
• Bazı metrikler (ör. VMAF), PyroWave’i bir miktar cömert değerlendirirken PSNR gibi metrikler iç hassasiyetin etkisini daha çok gösteriyor
• Görüntüde bulanıklık veya düşük kalite artifaktları olsa da modern oyun görselleri ve kullanım amacı düşünüldüğünde pratik kullanımda büyük bir sorun oluşturmuyor

Sonuç

• PyroWave, aşırı düşük gecikme ve yüksek hız gerektiren yerel oyun akışı alanında yenilikçi bir alternatif sunuyor
• Modern GPU mimarileriyle birlikte paralel işleme ve CBR denetimine özel olarak uyarlanmış durumda
• Kişisel bir proje olsa da DIY ultra hızlı akış çözümü olarak memnuniyet verici bir sonuç sunuyor

[GN⁺]

Hacker News görüşleri

• BBC tarafından geliştirilen, yalnızca intra kullanan wavelet tabanlı ultra düşük gecikmeli codec VC-2'den bahsediliyor. Bu codec telifsiz kullanılabiliyor ve şu anda yalnızca ffmpeg ile resmi BBC deposunda CPU tabanlı uygulamalar bulunuyor. Kendi yüksek lisans tezi kapsamında CUDA hızlandırmalı bir sürüm yapmayı planlıyor. Geçen yıl GSoC'ta yapılan Vulkan implementasyonları henüz tatmin edici değil. İnsanlara bu codec'e mutlaka göz atmalarını öneriyor

  • Vulkan implementasyonlarının neden yetersiz olduğunu biraz daha ayrıntılı açıklayabilir misin diye soruluyor. Bunun bir eleştiri değil, samimi bir merak olduğu belirtiliyor
  • VC-2 ile JPEG XS arasındaki görüntü kalitesi farkına dair deneyim soruluyor. Genel olarak JPEG XS'in daha yüksek görsel kalite sunduğu duyulmuş, ancak gerçek kullanım hissinin nasıl olduğu merak ediliyor

• Bu yazı, sinyal özelliklerine uygun bozulma toleransını ve tavizleri iyi eşleştirerek açıklayan harika bir örnek. Codec tasarlamak yerine seçen tarafta olsanız bile bu süreci izlemek iyi sonuçlar verebilir. Ultra düşük gecikmenin önemli olduğu alanlara ilgi duyuyorsanız, VSF'nin çeşitli alternatif codec'lerin özelliklerini özetlediği rapora (bağlantı) bakmak faydalı olabilir

• Video encoding hakkında neredeyse hiçbir şey bilmiyorum ama encoder oyun motoruyla az da olsa iş birliği yaparsa, video oyunu streaming'inde kaçırılan birçok pratik yaklaşım olabileceğini düşünüyorum. Örneğin çoğu rendering engine'in kendi amaçları için zaten bir motion prediction buffer'ı var; bunu encoding için de bedavaya kullanabiliriz. Ama muhtemelen yenilikleri engelleyen patentler vardır diye üzülüyor; bu yüzden pratikte zor olabilir

  • H.264'teki “motion vector”ların bit düzeyinde görüntü sıkıştırma tekniği olduğu, gerçek 3D oyunlarda kullanılan motion vector'larla aynı şey olmadığı vurgulanıyor. 3D oyunların motion vector'ları, nesnelerin 3D uzaydaki konum değişimini ifade ederken, H.264'te rastgele bir önceki frameden piksel blokları kopyalanıp farkın JPEG benzeri şekilde encode edilmesi kullanılıyor. Bu blok kopyalama yüzünden bant genişliği yetersiz olduğunda H.264 videonun kare kare bloklara ayrılmış gibi bozulduğu açıklanıyor
  • Ağ gecikmesinin 2 frame olduğu bir FPS oyunu örneği verilerek, oyun motoru UI ile 3D dünya görünümünü ayrı framebuffer'lar olarak sunarsa, istemci tarafında fare girdisi alınır alınmaz sunucudan gelen önceki framede yalnızca dünya görünümünün önceden kaydırılabileceği söyleniyor. VR oyunları zaten giriş gecikmesini telafi etmek için buna benzer yöntemler kullanıyor. Mükemmel olmasa da büyük fark yaratıyor; parallax da depth map kullanılırsa bir ölçüde sanal olarak üretilebilir
  • Sensör tabanlı video encoding'de olduğu gibi telefonun accelerometer ya da dijital pusula verileri encoding ipuçları için kullanılabilir (bağlantı). 2D oyunlarda arka plan ve büyük ön plan nesneleri için motion vector'lar doğru biçimde sağlanabilir. Overlay, HUD, skor tabelası, altyazı gibi 2D öğeler ayrı bir sıkıştırma yöntemiyle gönderilerek piksel netliği artırılabilir. HN'de insanların bu fikirlere bu kadar şüpheyle yaklaşmasının şaşırtıcı olduğu belirtiliyor
  • Ben de bunu hep merak etmişimdir. İstemcinin biraz compositing işini kendisinin yapabileceğini düşünüyorum. Örneğin arka plan ve ön plan farklı hızlarda render edilebilir ya da HUD önceliğe göre daha net bir codec kullanabilir. Stadia'nın kendi geliştirdiği oyunları olmasına rağmen basit video streaming yaklaşımı kullanmış olması bana hep şaşırtıcı gelmiştir. Belki çeşitli şeyler denediler ama mevcut video codec'lere kıyasla yeterince kazanç sağlayamadılar diye tahmin ediliyor
  • Eğer 2D sprite tabanlı bir oyunsa, encoder'a çok hassas motion vector'lar kolayca verilebilir. 3D rendering kullanan oyunlarda ise 3D nesnelere ait motion vector'ları 2D encoding'e uygun hale getirmenin pratikte ne kadar faydalı olacağı konusunda emin olunmadığı söyleniyor

• LLM (büyük dil modeli) ile oyundaki durumu her framede birkaç cümleyle özetleyip bunu ağ üzerinden gönderen, alıcı taraftaki LLM'in de bu metinden frame'i yeniden oluşturduğu bir yaklaşım öneriliyor. Gerçek zamanlı olması zor ve kaybı yüksek olurdu ama sıkıştırma oranı müthiş olurdu ve güncel trendlere de uygun olurdu deniyor

  • Frame 1 için örnek olarak, “Batıdaki tarlada duruyorsun ve beyaz evin ön kapısı tahtalarla kapatılmış. Burada küçük bir posta kutusu var” gibi bir açıklama verilebileceği gösteriliyor
  • Blockchain kullanılarak bu tür açıklamaların iletilmesiyle değiştirilemez kayıtlar da oluşturulabileceği ekleniyor
  • Bir gün oyunların herkesin kendi bilgisayarında doğrudan çalıştığı bir dönemin geri gelebileceği umuluyor
  • Bu fikrin ilginç olduğu söyleniyor

• Bu codec yaklaşımı, araştırma projesinde kullanmayı düşündüğüm şeyle neredeyse birebir aynı. Bilgi olsun diye, ticari projelerde patent havuzu meseleleri yüzünden ücretli standart JPEG-XS'in de (bağlantı1, bağlantı2) ultra düşük gecikme iddia ettiği ve daha güvenli bir tercih olabileceği belirtiliyor

  • JPEG-XS ultra düşük gecikmede güçlü ama daha fazla bant genişliği kullanıyor. Biz bunu film/TV post-prodüksiyonda gerçek zamanlı görüntü streaming'i için kullanıyoruz (örnek bağlantı). IntoPIX CUDA encoder/decoder ve SRT düşük gecikmeli taşıma yöntemi kullanılıyor. Ağ koşulları iyiyse toplam gecikmenin 16ms altında tutulması gayet mümkün. Veri merkezi ile şehir içindeki post-prodüksiyon stüdyoları arasında veya ülkeler arası 1GbE hatlarda çeşitli sıkıştırma oranlarıyla kullanım örnekleri olduğu söyleniyor
  • Patent havuzunun bir güvenlik ağı olmadığı belirtiliyor. Bu durum, patent köprüsünden geçmek için para ödemeniz ama sonrasında başka patent sorunları çıkarsa yine ek ödeme yapmanız gereken bir yapıya benzetiliyor

• VLC'nin kurucusunun ultra düşük gecikmeli bir streaming protokolü geliştirdiği söylenerek bir röportaj (bağlantı) ve demo videosu (bağlantı) paylaşılıyor

  • Bu alandaki kariyerine dayanarak, donanım encoder'larının ve H.264'ün gecikmesinin çok düşük olduğu vurgulanıyor. NVENC'te ek özellikler (çoklu frame tahmini, B-frame vb.) kapatılırsa encoding neredeyse anında yapılabiliyor. Gelişmiş işleme algoritmalarından ya da birkaç frame beklemeyi gerektiren yöntemlerden kaçınıldığında, GPU rendering biter bitmez <10ms içinde encode etmenin mümkün olduğu açıklanıyor
  • Bağlantıdaki videonun şu anda izlenemediği belirtiliyor

• Bu CODEC'in HTJ2K (High-Throughput JPEG 2000) benzeri algoritmalara dayandığı fark edilerek, yazar bunu görürse HTJ2K ile farklarını açıklamasının ilginç olacağı söyleniyor

• Yalnızca yerel ağ streaming'ine odaklanılıyorsa modern codec'lerin birçok özelliğine gerek olmadığı açıklanıyor. Bant genişliği yaklaşık 100Mbps ise işlem çok hızlı ve gecikme de çok düşük tutulabilir. Örnek olarak Microsoft DXT codec'inin modern codec özelliklerinin çoğuna sahip olmadığı (entropy encoding, motion compensation, deblocking yok), ama 4-8x sıkıştırma ve donanım decode desteği sayesinde toplam gecikmeyi azaltmada avantajlı olduğu belirtiliyor. Ancak ne kadar optimize edilirse edilsin ekranın kendisinin ayrıca 30-100ms gecikme yaratabildiğine dikkat çekiliyor

• Geliştirilen sonucun gerçekten etkileyici olduğu ve bir gün Moonlight ya da benzeri bir projede kullanıldığını görmeyi umduğu söyleniyor

  • Ben de aynı fikirdeyim deniyor; zamanı ve becerisi olsaydı bu codec desteğini Moonlight'a bizzat eklemek isteyeceği belirtiliyor. LAN üzerinde Sunshine/Moonlight ile Clair Obscure gibi oyunları stream ederken yeterince düşük gecikmenin gerçekten önemli olduğu söyleniyor

• Bu codec'in hâlâ niş ve uzmanlık gerektiren bir alan olması nedeniyle rakip codec'lerle karşılaştırma bulmanın zor olduğu yönündeki görüşe katılarak, H.264/AVC (sıfır gecikmeli ffmpeg seçeneği) ve JPEG XS ile benchmark sonuçlarının merak edildiği belirtiliyor. Hatta ffmpeg komut örneği ve ayrıntılı encoding parametreleri de paylaşılıyor