J’ai conçu moi-même PyroWave, un codec vidéo ultra-rapide pour le streaming de jeux

• Le streaming de jeux exige une latence extrêmement faible
• PyroWave atteint une vitesse extrême en supprimant la prédiction de mouvement et le codage entropique
• Son approche basée sur la transformée en ondelettes discrète (DWT) le distingue des codecs DCT classiques
• Grâce à un traitement parallèle par blocs de 32×32 et à un rate control rapide, l’encodage/décodage sur GPU est extrêmement rapide
• L’évaluation de la qualité montre des résultats suffisants dans certains scénarios, même face à H.264/HEVC/AV1

---

Exigences d’ultra-faible latence du streaming de jeux et limites des approches classiques

• Avec la hausse récente de la demande en streaming de gameplay, la transmission en temps réel d’un appareil à un autre via le réseau devient cruciale
• De la DMA au rendu, à l’encodage, à la transmission, au décodage et à l’affichage, la latence cumulée à chaque étape a un impact majeur sur l’expérience globale
• La solution traditionnelle consiste à utiliser des codecs vidéo accélérés par GPU comme H.264, HEVC ou AV1
• Mais en streaming, il est difficile d’utiliser des techniques de forte compression comme les B-frames, ce qui impose de fortes contraintes de latence et de débit binaire

Philosophie de conception : suppression de la prédiction de mouvement et du codage entropique

Suppression de la prédiction de mouvement – approche Intra-only

• La prédiction de mouvement des codecs vidéo classiques est supprimée afin de traiter chaque image indépendamment
• Le débit binaire augmente, mais cela apporte des avantages en résilience aux erreurs, en simplicité et en cohérence de qualité
• L’approche Intra-only a déjà été utilisée, notamment dans le cinéma numérique
• Cela la rend peu adaptée au streaming sur Internet, mais permet de bons résultats dans des environnements à large bande passante comme un LAN

Suppression du codage entropique

• Le codage entropique est entièrement exclu car il se prête mal au traitement parallèle sur GPU
• Un domaine jusque-là réservé aux ASIC ou aux équipements spécialisés est ainsi mis en œuvre en logiciel
• Cela ouvre la voie à une catégorie de codecs ultra-faible latence absents de FFmpeg

Une nouvelle approche avec la transformée en ondelettes (DWT)

• Au lieu de la DCT des codecs traditionnels, PyroWave adopte la transformée en ondelettes discrète (DWT)
• La transformée en ondelettes rappelle une structure de mip-map familière aux programmeurs graphiques
• L’image est séparée en plusieurs bandes, puis une quantification est appliquée à chacune
• Les bandes à haute fréquence sont quantifiées plus fortement afin d’exploiter au maximum les caractéristiques visuelles
• Ce processus est également lié au contrôle de débit (rate control)

Artéfacts typiques et limites des codecs à base d’ondelettes

• Au lieu des artéfacts de bloc du JPEG, les ondelettes produisent surtout du flou ou des effets de ringing
• Avec le flou dû au TAA déjà présent dans les jeux récents, cela ne constitue pas forcément un problème majeur en pratique

Empaquetage rapide du bitstream et parallélisation

• Les blocs de coefficients 32×32 sont traités indépendamment, de sorte qu’en cas de perte de paquets, l’impact se limite à un flou localisé
• Une organisation en sous-blocs 8×8 et 4×2 optimise le traitement parallèle à l’échelle des workgroups GPU
• Un encodage bitplane est utilisé, mais les données binaires sont stockées telles quelles sans codage entropique complexe
• Des techniques adaptées au GPU, comme le stockage SSBO sur 8 bits, maximisent l’efficacité mémoire et la vitesse de traitement

Un contrôle de débit précis et rapide

• Contrairement aux approches fondées sur le codage entropique, le système ajuste le débit en mesurant de manière répétée, bloc par bloc, le nombre de bits pouvant être omis
• Il calcule globalement une zone rate-distortion optimale afin de respecter strictement le CBR
• L’un des atouts des codecs à base d’ondelettes, à savoir l’arrêt anticipé par bitplane, est également obtenu ici en logiciel

Performances et efficacité en pratique

• En 1080p 4:2:0, l’encodage/décodage est terminé en 0,13 ms sur un GPU RX 9070 XT
• Chaque étape de traitement, dont la DWT et la quantification, exploite des optimisations FP16, avec un trade-off perceptible entre qualité et vitesse
• Des essais montrent que, même pour la 4K, un transfert après compression sur GPU est plus rapide qu’un transfert direct à la vitesse du PCI-e
• La vitesse obtenue peut être jusqu’à plus de 10 fois supérieure à celle de codecs matériels dédiés

Évaluation de la qualité et comparaison avec d’autres codecs

• Référence de comparaison : les encodeurs GPU de FFmpeg (H.264/HEVC/AV1) en mode Intra-only, CBR et latence minimale
• À 200 Mbps et 60 fps, les artéfacts de compression de PyroWave sont presque impossibles à distinguer à l’œil nu
• Sur diverses scènes de jeu, des indicateurs objectifs de qualité comme le VMAF, le SSIM et le PSNR montrent aussi des résultats suffisants
• Certains indicateurs, comme le VMAF, évaluent PyroWave un peu généreusement, tandis que le PSNR révèle l’influence de la précision interne
• L’image présente du flou ou des artéfacts de moindre qualité, mais cela ne pose pas de problème majeur en usage réel compte tenu du rendu des jeux modernes et de l’objectif visé

Conclusion

• PyroWave propose une alternative innovante pour le streaming local de jeux nécessitant un traitement ultra-faible latence et très rapide
• Il est particulièrement adapté au traitement parallèle et au contrôle CBR en phase avec les architectures GPU modernes
• Bien qu’il s’agisse d’un projet personnel, le résultat est très satisfaisant comme solution DIY de streaming ultra-rapide

[GN⁺]

Commentaires sur Hacker News

• Discussion autour de VC-2, un codec intra uniquement à base d’ondelettes et à très faible latence développé par la BBC. Ce codec est libre de droits, et pour l’instant il n’existe que des implémentations CPU dans ffmpeg et dans le dépôt officiel de la BBC. L’auteur prévoit d’en réaliser une version accélérée par CUDA dans le cadre de son mémoire de master. Les implémentations Vulkan menées lors du GSoC l’an dernier ne sont pas encore satisfaisantes. Il recommande vivement aux gens de jeter un œil à ce codec

  • Demande s’il est possible d’expliquer plus en détail pourquoi les implémentations Vulkan sont insuffisantes. La question n’a pas pour but de critiquer, c’est une vraie curiosité
  • Demande un retour d’expérience sur la différence de qualité d’image entre VC-2 et JPEG XS. Il a entendu dire qu’en général JPEG XS offre une meilleure qualité visuelle, mais il se demande ce que cela donne en pratique

• Cet article est un excellent exemple d’explication sur la manière d’associer correctement la tolérance à la dégradation et les compromis aux caractéristiques du signal. Même lorsqu’on choisit un codec sans le concevoir soi-même, suivre cette démarche peut mener à de bons résultats. Si vous vous intéressez aux domaines où l’ultra-faible latence est importante, il peut être utile de consulter le rapport de la VSF qui résume les caractéristiques de plusieurs codecs alternatifs (lien)

• Je n’y connais presque rien en encodage vidéo, mais j’ai l’impression que si l’encodeur collaborait ne serait-ce qu’un peu avec le moteur de jeu, il y aurait beaucoup d’approches pratiques encore inexploitées pour le streaming de jeux vidéo. Par exemple, la plupart des moteurs de rendu disposent déjà de leurs propres buffers de prédiction de mouvement pour d’autres usages, et on pourrait les réutiliser gratuitement pour l’encodage. Dommage qu’il y ait probablement des brevets qui bloquent ce type d’invention en pratique

  • Il souligne que les « vecteurs de mouvement » du H.264 ne sont qu’une technique de compression d’image au niveau du bit, et qu’ils sont différents des vecteurs de mouvement utilisés dans un vrai jeu 3D. Dans un jeu 3D, les vecteurs de mouvement représentent le déplacement des objets dans l’espace 3D, tandis qu’en H.264 on copie simplement des blocs de pixels depuis une image précédente arbitraire puis on encode la différence à la manière du JPEG. Il explique que c’est cette copie par blocs qui fait qu’en cas de bande passante insuffisante, une vidéo H.264 semble se dégrader en gros carrés
  • En prenant l’exemple d’un FPS avec 2 frames de latence réseau, il explique que si le moteur de jeu fournit l’interface et la vue du monde 3D dans des framebuffers séparés, on peut, côté client, déplacer à l’avance uniquement la vue du monde de la frame précédente reçue du serveur dès qu’on capte l’entrée de la souris. Les jeux VR compensent déjà la latence d’entrée de cette manière. Ce n’est pas parfait, mais cela fait une grande différence, et même la parallaxe pourrait être simulée dans une certaine mesure à l’aide d’une depth map
  • Comme dans l’encodage vidéo assisté par capteurs, on pourrait utiliser les informations de l’accéléromètre ou de la boussole numérique du téléphone pour fournir des indices à l’encodage (lien). Pour les jeux 2D, on peut fournir avec précision les vecteurs de mouvement de l’arrière-plan et des gros objets de premier plan. Les éléments 2D comme les overlays, le HUD, le score ou les sous-titres pourraient être transmis avec une méthode de compression distincte afin d’améliorer la netteté des pixels. Il se dit surpris de voir autant de scepticisme sur HN face à ce genre d’idées
  • Je me pose toujours la même question. À mon avis, le client pourrait très bien prendre en charge un peu de compositing lui-même. Par exemple, en rendant l’arrière-plan et le premier plan à des fréquences différentes, ou en utilisant pour le HUD un codec plus net selon sa priorité. J’ai toujours été surpris que Stadia, malgré ses jeux propriétaires, ait reposé sur un simple streaming vidéo. Ils ont peut-être tenté diverses approches sans obtenir un gain suffisant face aux codecs vidéo classiques
  • Pour un jeu à sprites 2D, il serait facile de fournir à l’encodeur des vecteurs de mouvement très précis. Pour un jeu en rendu 3D, on ne sait pas vraiment si convertir les vecteurs de mouvement des objets 3D pour les adapter à un encodage 2D serait réellement utile

• Proposition d’utiliser un LLM (grand modèle de langage) pour résumer à chaque frame la situation dans le jeu en quelques phrases envoyées sur le réseau, puis laisser un LLM côté réception reconstruire la frame à partir de ce texte. Ce n’est pas réaliste en temps réel et la perte serait énorme, mais le taux de compression serait spectaculaire et cela irait dans le sens de la tendance actuelle

  • Exemple pour la frame 1 : « Vous vous tenez dans le champ à l’ouest, et la porte d’entrée de la maison blanche est condamnée par des planches. Il y a ici une petite boîte aux lettres »
  • Il ajoute qu’en transmettant ces descriptions via une blockchain, on pourrait en plus en faire un enregistrement immuable
  • Il espère qu’un jour viendra où les jeux s’exécuteront directement sur l’ordinateur de chaque utilisateur
  • Il dit trouver l’idée intéressante

• Cette approche de codec correspond presque exactement à ce que je voulais utiliser dans un projet de recherche. À titre indicatif, pour un projet commercial, le standard payant JPEG-XS (lien1, lien2) peut aussi être un choix plus sûr, car il revendique lui aussi une latence ultra-faible, avec en plus la question des patent pools

  • JPEG-XS a l’avantage de l’ultra-faible latence, mais utilise davantage de bande passante. Nous l’utilisons pour du streaming d’images en temps réel dans la postproduction cinéma/TV (cas d’usage). Nous utilisons l’encodeur/décodeur CUDA d’IntoPIX ainsi que le transport faible latence SRT. Sur un réseau confortable, il est tout à fait possible d’atteindre une latence totale inférieure à 16 ms. Il existe des cas d’usage avec plusieurs taux de compression entre les datacenters et les studios de postproduction en centre-ville, ou même sur des liaisons 1GbE entre pays
  • Il précise qu’un patent pool n’est pas un filet de sécurité. C’est plutôt comme payer pour traverser un pont de brevets, puis devoir encore payer si d’autres problèmes de brevets apparaissent après

• Il partage une interview (lien) et une vidéo de démonstration (lien) en indiquant que le fondateur de VLC est en train de développer un protocole de streaming à très faible latence

  • Fort de son expérience dans ce domaine, il insiste sur le fait que les encodeurs matériels et H.264 peuvent déjà offrir une latence très faible. NVENC peut encoder presque instantanément si l’on désactive les fonctions annexes (prédiction multi-images, B-frames, etc.). Tant qu’on évite les algorithmes de traitement avancés ou les approches qui exigent d’attendre plusieurs frames, l’encodage peut être réalisé en moins de 10 ms juste après la fin du rendu GPU
  • Il mentionne que la vidéo liée n’est actuellement plus visionnable

• Il remarque que ce CODEC repose sur une famille d’algorithmes similaire à HTJ2K (High-Throughput JPEG 2000), et estime que si l’auteur passe par là, il serait intéressant qu’il explique en quoi il diffère de HTJ2K

• Il explique que si l’on se concentre uniquement sur le streaming en réseau local, beaucoup de fonctionnalités des codecs modernes ne sont pas nécessaires. Avec environ 100 Mbps de bande passante, on peut privilégier une implémentation très rapide et peu latente. Il cite par exemple le codec Microsoft DXT, qui ne possède pratiquement aucune des fonctions des codecs modernes (pas d’encodage entropique, pas de compensation de mouvement, pas de deblocking), mais permet un taux de compression de 4 à 8x avec décodage matériel, ce qui aide à réduire la latence totale. Il souligne toutefois que, même avec des optimisations, l’écran lui-même ajoute encore 30 à 100 ms de latence supplémentaire

• Le résultat du développement est vraiment impressionnant, et il espère qu’un jour cela sera intégré à Moonlight ou à un projet similaire

  • Il dit penser la même chose et ajoute que, s’il avait eu le temps et les compétences, il aurait aimé ajouter lui-même la prise en charge de ce codec à Moonlight. Il mentionne que lorsqu’on streame sur un LAN avec Sunshine/Moonlight des jeux comme Clair Obscure, il est indispensable d’avoir une latence suffisamment faible

• Citant l’avis selon lequel ce codec reste encore un domaine peu connu et spécialisé, ce qui rend difficile de trouver des comparaisons avec les codecs concurrents, il dit être curieux de voir des benchmarks face à H.264/AVC (avec option ffmpeg zéro latence) et à JPEG XS. Il partage même un exemple de commande ffmpeg et des paramètres d’encodage détaillés