Ich habe den ultraschnellen Game-Streaming-Video-Codec PyroWave selbst entworfen

• Game-Streaming erfordert zwingend eine sehr niedrige Latenz
• PyroWave erreicht extreme Geschwindigkeit, indem Bewegungsvorhersage und Entropiecodierung entfernt werden
• Der Ansatz basiert auf der diskreten Wavelet-Transformation (DWT) und unterscheidet sich damit von herkömmlichen DCT-Codecs
• Durch parallele Verarbeitung in 32×32-Blöcken und schnelle Rate-Control ist das Kodieren/Dekodieren auf der GPU sehr schnell
• Die Qualitätsbewertung zeigt im Vergleich zu H.264/HEVC/AV1 in bestimmten Situationen ausreichend gute Ergebnisse

---

Die Anforderungen an ultraniedrige Latenz beim Game-Streaming und die Grenzen bestehender Verfahren

• Mit der zuletzt gestiegenen Nachfrage nach Gameplay-Streaming wird die Echtzeitübertragung über das Netzwerk von einem Gerät auf ein anderes immer wichtiger
• Von DMA, Rendering, Kodierung, Übertragung und Dekodierung bis zur Bildausgabe hat die in jedem Schritt aufsummierte Latenz großen Einfluss auf das gesamte Erlebnis
• Die traditionelle Lösung besteht im Einsatz von GPU-beschleunigten Video-Codecs wie H.264, HEVC oder AV1
• Beim Streaming lassen sich jedoch Hochkompressionsverfahren wie B-Frames nicht nutzen, wodurch die Einschränkungen bei Latenz und Bitrate deutlich zunehmen

Designphilosophie: Verzicht auf Bewegungsvorhersage und Entropiecodierung

Verzicht auf Bewegungsvorhersage – Intra-Only-Ansatz

• Die Bewegungsvorhersage klassischer Video-Codecs wurde entfernt, sodass jedes Frame einzeln behandelt wird
• Dadurch steigt zwar die Bitrate, es ergeben sich aber Vorteile bei Fehlerrobustheit, Einfachheit und gleichbleibender Qualität
• Auch im Digital Cinema gibt es bereits Erfahrungen mit Intra-Only-Verfahren
• Damit ist der Ansatz für Internet-Streaming ungeeignet, kann aber in Umgebungen mit hoher Bandbreite wie LANs gute Ergebnisse liefern

Verzicht auf Entropiecodierung

• Entropiecodierung wurde vollständig ausgeschlossen, da sie für parallele Verarbeitung auf GPUs ungeeignet ist
• Ein Bereich, der bislang nur für ASICs oder Spezialhardware existierte, wird damit als Softwarelösung realisiert
• Damit wird ein Feld von ultraniedrigen Latenz-Codecs außerhalb von FFmpeg erschlossen

Ein neuer Ansatz mit Wavelet-Transformation (DWT)

• Anstelle der DCT herkömmlicher Codecs wird die diskrete Wavelet-Transformation (DWT) eingesetzt
• Die Wavelet-Transformation ähnelt einer Mipmap-Struktur, mit der Grafikprogrammierer vertraut sind
• Das Bild wird in mehrere Bänder aufgeteilt, auf die jeweils Quantisierung angewendet wird
• Hochfrequenzbänder werden stärker quantisiert, um visuelle Eigenschaften möglichst gut auszunutzen
• Dieser Prozess ist auch mit der Rate-Control verknüpft

Typische Artefakte und Grenzen eines Wavelet-basierten Codecs

• Statt der Blocking-Artefakte von JPEG treten bei Wavelets hauptsächlich Unschärfe oder Ringing-Effekte auf
• Das überschneidet sich mit der durch TAA verursachten Unschärfe in modernen Spielen und ist in der Praxis womöglich kein großes Problem

Schnelles Bitstream-Packing und Parallelisierung

• 32×32-Koeffizientenblöcke werden unabhängig verarbeitet, sodass sich die Auswirkungen von Paketverlusten auf lokale Unschärfe beschränken
• Durch 8×8- und 4×2-Unterblöcke wird die Parallelverarbeitung auf Ebene von GPU-Workgroups optimiert
• Es wird Bitplane-Encoding verwendet, die Rohbitdaten werden jedoch ohne komplexe Entropiecodierung gespeichert
• Mit GPU-freundlichen Verfahren wie SSBO-8-Bit-Speicherung werden Speichereffizienz und Verarbeitungsgeschwindigkeit maximiert

Präzise und schnelle Rate-Control

• Anders als bei klassischer Entropiecodierung wird die Anzahl ausgelassener Bits pro Block wiederholt gemessen und gespeichert, um das Verhältnis passend zu steuern
• Durch die globale Berechnung optimaler Rate-Distortion-Bereiche wird CBR strikt eingehalten
• Die für Wavelet-artige Codecs typische frühzeitige Beendigung pro Bitplane wird auch in Software erreicht

Praktische Leistung und Effizienz

• Bei 1080p 4:2:0 sind Kodierung und Dekodierung auf einer RX 9070 XT GPU in 0,13 ms abgeschlossen
• Für DWT, Quantisierung und andere Verarbeitungsschritte werden FP16-Optimierungen genutzt, wodurch der Trade-off zwischen Qualität und Geschwindigkeit spürbar wird
• Experimente zeigen, dass bei 4K-Video Übertragung nach GPU-Kompression schneller ist als die PCI-e-Übertragungsgeschwindigkeit
• Es wird eine Geschwindigkeit erreicht, die bis zu mehr als 10-mal höher ist als bei dedizierten Hardware-Codecs

Qualitätsbewertung und Vergleich mit anderen Codecs

• Vergleichsgruppe: GPU-Encoder von FFmpeg (H.264/HEVC/AV1) im Intra-Only-, CBR- und Minimal-Latenz-Modus
• PyroWave zeigt bei 200 Mbps und 60 fps visuell kaum noch unterscheidbare Kompressionsartefakte
• Für verschiedene Spielszenen werden auch mit objektiven Qualitätsmetriken wie VMAF, SSIM und PSNR ausreichend gute Ergebnisse erzielt
• Bestimmte Metriken wie VMAF bewerten PyroWave etwas wohlwollend, während PSNR den Einfluss der internen Präzision stärker sichtbar macht
• Zwar gibt es Unschärfen und Artefakte geringerer Qualität, doch angesichts moderner Spielgrafik und des Einsatzzwecks ist das in der Praxis kein großes Problem

Fazit

• PyroWave bietet für lokales Game-Streaming mit extrem niedriger Latenz und hoher Geschwindigkeit eine innovative Alternative
• In Verbindung mit modernen GPU-Architekturen ist es besonders auf Parallelverarbeitung und CBR-Steuerung zugeschnitten
• Es ist zwar ein persönliches Projekt, erreicht aber als DIY-Lösung für ultraschnelles Streaming eine hohe Zufriedenheit

[GN⁺]

Hacker-News-Kommentare

• Es geht um VC-2, einen von der BBC entwickelten wavelet-basierten Ultra-Low-Latency-Codec nur für Intra-Frames. Der Codec ist lizenzfrei nutzbar, und derzeit existieren nur CPU-basierte Implementierungen in ffmpeg und im offiziellen BBC-Repository. Der Autor plant, als Teil seiner Masterarbeit eine CUDA-beschleunigte Version zu erstellen. Die im letzten GSoC entstandenen Vulkan-Implementierungen seien bislang noch nicht zufriedenstellend. Er empfiehlt allen, sich diesen Codec unbedingt einmal anzusehen

  • Es wird gefragt, ob man genauer erläutern könne, warum die Vulkan-Implementierungen unzureichend seien. Das sei nicht als Kritik gemeint, sondern aus ehrlichem Interesse
  • Es wird nach Erfahrungen mit dem Qualitätsunterschied zwischen VC-2 und JPEG XS gefragt. Allgemein habe man gehört, dass JPEG XS eine höhere visuelle Qualität liefere, aber interessant sei, wie es sich in der Praxis anfühle

• Dieser Beitrag sei ein hervorragendes Beispiel dafür, wie man die zulässige Verzerrung passend zu den Signaleigenschaften und den jeweiligen Trade-offs erklärt. Selbst wenn man keinen Codec entwirft, sondern nur auswählt, könne man durch dieses Vorgehen gute Ergebnisse erzielen. Wer sich für Bereiche interessiert, in denen extrem geringe Latenz wichtig ist, finde den Bericht der VSF zu den Eigenschaften verschiedener alternativer Codecs nützlich (Link)

• Ich weiß fast nichts über Video-Encoding, aber ich denke, dass es beim Streaming von Videospielen viele praktische Ansätze gibt, die übersehen werden, wenn der Encoder auch nur ein wenig mit der Game-Engine zusammenarbeitet. In den meisten Rendering-Engines gibt es zum Beispiel bereits Motion-Prediction-Buffer für eigene Zwecke, die man quasi kostenlos auch fürs Encoding verwenden könnte. Schade nur, dass es wohl Patente gibt, die solche Erfindungen verhindern könnten

  • Es wird betont, dass die „Motion Vectors“ in H.264 lediglich eine bitbasierte Bildkompressionstechnik sind und nicht mit den Motion Vectors identisch, die in echten 3D-Spielen verwendet werden. In 3D-Spielen beschreiben Motion Vectors die Positionsänderung von Objekten im 3D-Raum, während H.264 Pixelblöcke aus beliebigen vorherigen Frames kopiert und die Differenz dann JPEG-artig encodiert. Dieses Blockkopieren erkläre auch, warum H.264-Videos bei Bandbreitenmangel in quadratische Fragmente zerfallen
  • Als Beispiel wird ein FPS-Spiel mit zwei Frames Netzwerklatenz genannt: Wenn die Game-Engine UI und 3D-Weltansicht als getrennte Framebuffer bereitstellt, könnte der Client unmittelbar nach einer Mauseingabe auf Basis des zuvor vom Server empfangenen Frames zumindest die Weltansicht vorab verschieben. VR-Spiele kompensieren Input-Latenz bereits auf ähnliche Weise. Perfekt ist das nicht, aber es macht einen großen Unterschied, und Parallaxe ließe sich mit einer Depth Map teilweise auch künstlich nachbilden
  • Ähnlich wie beim sensorbasierten Video-Encoding könnte man Hinweise fürs Encoding über den Beschleunigungssensor oder den digitalen Kompass eines Smartphones geben (Link). Bei 2D-Spielen ließen sich Motion Vectors für den Hintergrund und große Vordergrundobjekte präzise übergeben. 2D-Elemente wie Overlays, HUD, Punktetafeln oder Untertitel könnten mit einem separaten Kompressionsverfahren übertragen werden, um die Pixelschärfe zu erhöhen. Es wird als überraschend bezeichnet, dass auf HN so viele Menschen diesen Ideen skeptisch gegenüberstehen
  • Ich frage mich das auch schon lange. Ich denke, der Client könnte ein wenig Compositing durchaus selbst übernehmen. Zum Beispiel könnte man Hintergrund und Vordergrund mit unterschiedlicher Frequenz rendern oder für das HUD je nach Priorität einen klareren Codec verwenden. Dass Stadia trotz eigener Spiele nur simples Videostreaming eingesetzt hat, fand ich immer überraschend. Vielleicht hat man viele solcher Ansätze ausprobiert, aber gegenüber bestehenden Video-Codecs keinen ausreichenden Vorteil erzielt
  • Bei einem 2D-Sprite-Spiel könnte man dem Encoder sehr präzise Motion Vectors leicht zur Verfügung stellen. Bei 3D-gerenderten Spielen ist man sich nicht sicher, ob die Umrechnung von Motion Vectors für 3D-Objekte in eine Form, die für 2D-Encoding nützlich ist, in der Praxis wirklich helfen würde

• Es wird vorgeschlagen, mit einem LLM (Large Language Model) die Spielsituation in jedem Frame in wenigen Sätzen zusammenzufassen, diese über das Netzwerk zu übertragen und auf der Empfängerseite mit einem LLM daraus wieder einen Frame zu rekonstruieren. In Echtzeit sei das schwierig und sehr verlustbehaftet, aber die Kompressionsrate wäre enorm und entspräche dem aktuellen Trend

  • Als Beispiel für Frame 1 wird gezeigt, dass man etwas beschreiben könnte wie: „Du stehst auf einem Feld im Westen, und die Vordertür des weißen Hauses ist mit Brettern vernagelt. Hier gibt es einen kleinen Briefkasten“
  • Ergänzend wird erwähnt, dass man mithilfe einer Blockchain solche Beschreibungen auch unveränderlich protokollieren könnte
  • Es wird die Hoffnung geäußert, dass irgendwann wieder eine Zeit kommen könnte, in der Spiele direkt auf den Rechnern der Nutzer laufen
  • Es wird gesagt, dass die Idee interessant sei

• Dieser Codec-Ansatz entspreche fast genau dem, was ich für ein Forschungsprojekt nutzen wollte. Der Hinweis lautet allerdings, dass für kommerzielle Projekte wegen möglicher Patent-Pool-Probleme der kostenpflichtige Standard JPEG-XS (Link1, Link2) womöglich die sicherere Wahl ist, da auch er Ultra-Low-Latency beansprucht

  • JPEG-XS habe Vorteile bei Ultra-Low-Latency, benötige aber mehr Bandbreite. Wir setzen es für Echtzeit-Bildstreaming in der Film-/TV-Postproduktion ein (Praxisbeispiel). Verwendet werden IntoPIX-CUDA-Encoder/-Decoder sowie SRT für die latenzarme Übertragung. In einem guten Netzwerk seien insgesamt unter 16 ms Latenz gut erreichbar. Es gebe verschiedene Einsatzszenarien mit unterschiedlichen Kompressionsraten, etwa zwischen Rechenzentren und städtischen Postproduktionsstudios oder auch über internationale 1GbE-Leitungen
  • Es wird klargestellt, dass ein Patent-Pool kein Sicherheitsnetz ist. Es sei eher so, als bezahle man eine Maut, um eine Patentbrücke zu überqueren, könne danach aber trotzdem noch auf weitere Patentprobleme stoßen und erneut zahlen müssen

• Es wird geteilt, dass der VLC-Gründer an einem Ultra-Low-Latency-Streaming-Protokoll arbeitet, zusammen mit einem Interview (Link) und einem Demo-Video (Link)

  • Basierend auf Erfahrung in diesem Bereich wird betont, dass Hardware-Encoder und H.264 sehr geringe Latenzen haben. NVENC kann nahezu sofort encodieren, wenn Zusatzfunktionen wie Multi-Frame-Prediction, B-Frames usw. deaktiviert sind. Solange man auf fortgeschrittene Verarbeitungsalgorithmen oder Verfahren verzichtet, die auf mehrere wartende Frames angewiesen sind, sei ein Encoding innerhalb von <10 ms nach Abschluss des GPU-Renderings möglich
  • Es wird erwähnt, dass das verlinkte Video derzeit nicht abspielbar ist

• Es wird erkannt, dass dieser CODEC-Ansatz auf einem ähnlichen Algorithmus wie HTJ2K (High-Throughput JPEG 2000) beruht, und angemerkt, dass es interessant wäre, wenn der Autor – falls er mitliest – die Unterschiede zu HTJ2K erläutern könnte

• Es wird erklärt, dass man viele Funktionen moderner Codecs nicht benötigt, wenn man sich nur auf Streaming im lokalen Netzwerk konzentriert. Wenn allein etwa 100 Mbps Bandbreite verfügbar sind, kann man die Verarbeitung sehr schnell halten und die Latenz gering machen. Als Beispiel wird der Microsoft-DXT-Codec genannt: Er besitzt kaum moderne Codec-Funktionen (keine Entropie-Codierung, keine Motion Compensation, kein Deblocking), bietet aber eine 4- bis 8-fache Kompression und Hardware-Decoding, was für die Senkung der Gesamtlatenz vorteilhaft ist. Allerdings wird darauf hingewiesen, dass selbst dann das Display selbst noch zusätzliche 30 bis 100 ms Latenz verursachen kann

• Es wird gesagt, dass das Entwicklungsergebnis wirklich beeindruckend sei, und die Hoffnung geäußert, dass es eines Tages in Moonlight oder einem ähnlichen Projekt eingesetzt wird

  • Dem wird zugestimmt, mit dem Zusatz, dass man die Unterstützung für diesen Codec gern selbst in Moonlight eingebaut hätte, wenn Zeit und Können dafür gereicht hätten. Beim Streaming von Spielen wie Clair Obscure über Sunshine/Moonlight im LAN sei ausreichend geringe Latenz wirklich wichtig

• Unter Verweis auf die Einschätzung, dass dieser Codec noch ein eher unbekanntes und spezialisiertes Feld sei und sich daher schwer Vergleichsmaterial zu konkurrierenden Codecs finden lasse, wird gesagt, dass Benchmarks gegenüber H.264/AVC (mit ffmpeg-Optionen für Zero Latency) und JPEG XS interessant wären. Dazu wurden sogar ffmpeg-Befehlsbeispiele und detaillierte Encoding-Parameter geteilt