Diseñé mi propio códec de video PyroWave para streaming de juegos ridículamente rápido

• El streaming de juegos exige una latencia extremadamente baja
• PyroWave logra una velocidad extrema al eliminar la predicción de movimiento y la codificación por entropía
• Se diferencia de los códecs tradicionales basados en DCT al usar un enfoque basado en transformada wavelet discreta (DWT)
• Con procesamiento paralelo por bloques de 32×32 y un control de tasa rápido, la codificación y decodificación en GPU son muy veloces
• En evaluación de calidad, muestra resultados suficientemente buenos en ciertos escenarios incluso frente a H.264/HEVC/AV1

---

Requisitos de latencia ultrabaja del streaming de juegos y límites de los enfoques existentes

• A medida que aumenta la demanda de streaming de gameplay, se vuelve crucial la transmisión en tiempo real de un dispositivo a otro a través de la red
• La latencia acumulada en cada etapa, desde DMA, renderizado, codificación, transmisión, decodificación y salida en pantalla, afecta fuertemente la experiencia general
• La solución tradicional es usar códecs de video con aceleración por GPU como H.264, HEVC y AV1
• Pero en streaming no se pueden usar técnicas de alta compresión como los B-frames, lo que impone fuertes limitaciones de latencia y bitrate

Filosofía de diseño: eliminar la predicción de movimiento y la codificación por entropía

Eliminar la predicción de movimiento – enfoque Intra-Only

• Se elimina la predicción de movimiento de los códecs de video convencionales para tratar cada cuadro de forma independiente
• Como resultado, el bitrate aumenta, pero hay ventajas en resistencia a errores, simplicidad y consistencia de calidad
• El enfoque Intra-only ya se ha usado también en cine digital
• Por eso no es adecuado para streaming por internet, pero puede dar buenos resultados en entornos de alto ancho de banda como una LAN

Eliminar la codificación por entropía

• La codificación por entropía se excluye por completo porque perjudica el procesamiento paralelo en GPU
• Se implementa por software un terreno que antes existía solo para ASICs o equipos especializados
• Abre camino en el área de los códecs ultrabajos en latencia que no existen en FFmpeg

Un nuevo enfoque con transformada wavelet (DWT)

• En lugar de la DCT de los códecs tradicionales, adopta la transformada wavelet discreta (DWT)
• La transformada wavelet es similar a la estructura de mip-map, familiar para programadores gráficos
• Divide la imagen en varias bandas y aplica cuantización a cada una
• Las bandas de alta frecuencia se cuantizan con mayor agresividad para aprovechar al máximo las características visuales
• Este proceso también está vinculado al control de tasa (rate control)

Artefactos típicos y límites de los códecs basados en wavelets

• En lugar de los artefactos de bloqueo de JPEG, los wavelets suelen producir principalmente desenfoque o ringing
• Como esto se superpone con el desenfoque causado por TAA en juegos recientes, en la práctica puede no ser un gran problema

Empaquetado de bitstream de alta velocidad y paralelización

• Los bloques de coeficientes de 32×32 se procesan de forma independiente para limitar el impacto de la pérdida de paquetes a solo un desenfoque local
• Con subbloques de 8×8 y 4×2, se optimiza el procesamiento paralelo a nivel de workgroups de GPU
• Se usa codificación por bitplane, pero se almacenan datos de bits crudos sin codificación por entropía compleja
• Métodos amigables con GPU como almacenamiento SSBO de 8 bits maximizan la eficiencia de memoria y la velocidad de procesamiento

Control de tasa preciso y rápido

• A diferencia de los métodos tradicionales con codificación por entropía, se ajusta la tasa midiendo y almacenando repetidamente cuántos bits se omiten en cada bloque
• Se calcula globalmente el tramo óptimo de rate-distortion para cumplir estrictamente con CBR
• La fortaleza de los códecs tipo wavelet, el corte temprano por bitplane, también se logra por software

Rendimiento y eficiencia reales

• En 1080p 4:2:0, la codificación y decodificación se completan en 0.13 ms en una GPU RX 9070 XT
• Se aprovechan optimizaciones FP16 en cada etapa, como DWT y cuantización, con un claro trade-off entre calidad y velocidad
• En 4K, experimentos muestran que comprimir en la GPU antes de transferir es más rápido que la velocidad de transferencia por PCI-e
• Se logra una velocidad hasta más de 10 veces superior incluso a códecs con hardware dedicado

Evaluación de calidad y comparación con otros códecs

• Grupo de comparación: codificadores GPU de FFmpeg (H.264/HEVC/AV1) en modo Intra-only, CBR y mínima latencia
• Con 200 Mbps y 60 fps, en PyroWave los artefactos de compresión son casi indistinguibles a simple vista
• En distintas escenas de juegos, también obtiene resultados suficientemente buenos en métricas objetivas de calidad como VMAF, SSIM y PSNR
• Algunas métricas específicas (como VMAF) tienden a favorecer un poco a PyroWave, mientras que PSNR revela el impacto de la precisión interna
• Aunque hay desenfoque o artefactos de menor calidad en la imagen, no representan un gran problema práctico dado el aspecto visual de los juegos modernos y el uso previsto

Conclusión

• PyroWave presenta una alternativa innovadora para el streaming local de juegos que requiere latencia ultrabaja y procesamiento de alta velocidad
• Está especialmente orientado al procesamiento paralelo y al control CBR en conjunto con arquitecturas GPU modernas
• Aunque es un proyecto personal, ofrece un alto nivel de satisfacción como solución DIY de streaming ultrarrápido

[GN⁺]

Opiniones de Hacker News

• Habla sobre VC-2, un códec intra basado en wavelets y de latencia ultrabaja desarrollado por la BBC. Este códec puede usarse sin regalías y, por ahora, solo existen implementaciones basadas en CPU en ffmpeg y en el repositorio oficial de la BBC. Planea crear una versión acelerada con CUDA como tesis de maestría. Las implementaciones en Vulkan realizadas el año pasado en GSoC todavía no resultan satisfactorias. Recomienda mucho que la gente le eche un vistazo a este códec

  • Pregunta si puede explicar con más detalle por qué las implementaciones en Vulkan son insuficientes. Aclara que no es con intención de criticar, sino por curiosidad genuina
  • Pregunta por la experiencia respecto a la diferencia de calidad de imagen entre VC-2 y JPEG XS. Menciona que, en general, ha oído que JPEG XS ofrece una calidad visual más alta, pero le interesa saber cómo se siente en uso real

• Este artículo es un excelente ejemplo de cómo explicar bien la tolerancia a la distorsión y los trade-offs ajustándolos a las características de la señal. Incluso si uno está en la posición de elegir un códec en lugar de diseñarlo, seguir este proceso puede dar buenos resultados. Si te interesa el área donde la latencia ultrabaja es importante, puede ser útil consultar un reporte de VSF que resume las características de varios códecs alternativos (enlace)

• No sé casi nada de codificación de video, pero creo que si el encoder cooperara aunque sea un poco con el motor del juego, habría muchos enfoques prácticos que se están desaprovechando en el streaming de videojuegos. Por ejemplo, la mayoría de los motores de renderizado ya tienen buffers de predicción de movimiento para sus propios fines, y eso podría reutilizarse gratis para la codificación. Lamenta que probablemente existan patentes que bloqueen este tipo de invenciones, así que quizá en la práctica no sea tan fácil

  • Enfatiza que los “vectores de movimiento” de H.264 son solo una técnica de compresión de imagen a nivel de bits, y no son lo mismo que los vectores de movimiento que se usan en juegos 3D reales. Los vectores de movimiento en juegos 3D representan el cambio de posición de los objetos en el espacio 3D, mientras que en H.264 se copian bloques de píxeles de cuadros anteriores arbitrarios y luego la diferencia se codifica de forma similar a JPEG. Explica que, por esta copia de bloques, cuando falta ancho de banda el video H.264 termina viéndose roto en pedazos cuadrados
  • Pone como ejemplo un juego FPS con 2 cuadros de latencia de red: si el motor del juego entregara la UI y la vista del mundo 3D en framebuffers separados, en cuanto el cliente reciba una entrada del mouse podría adelantar localmente solo la vista del mundo sobre el cuadro anterior recibido del servidor. Los juegos de VR ya compensan la latencia de entrada de esta forma. No es perfecto, pero marca una gran diferencia, y el paralaje también podría simularse en cierta medida usando mapas de profundidad
  • Igual que en la codificación de video basada en sensores, se podrían usar datos del acelerómetro o de la brújula digital del teléfono para dar pistas de codificación (enlace). En juegos 2D, se podrían proporcionar con precisión los vectores de movimiento del fondo y de los objetos grandes en primer plano. Elementos 2D como overlays, HUD, marcador o subtítulos podrían enviarse con un método de compresión aparte para mejorar la nitidez de los píxeles. Comenta que le sorprende que en HN haya tanta gente escéptica con ideas así
  • Yo también siempre me he preguntado eso. Creo que el cliente podría encargarse directamente de algo de composición. Por ejemplo, renderizar el fondo y el primer plano con frecuencias distintas, o usar para el HUD un códec claro según la prioridad. Siempre me sorprendió que Stadia, aun teniendo juegos propios, usara un enfoque de simple streaming de video. Supone que quizá probaron varias ideas, pero no obtuvieron una ganancia suficiente frente a los códecs de video tradicionales
  • En un juego 2D con sprites, sería fácil proporcionar al encoder vectores de movimiento muy precisos. En juegos con renderizado 3D, no está seguro de si convertir los vectores de movimiento de objetos 3D a algo adecuado para codificación 2D ayudaría realmente en la práctica

• Propone un enfoque en el que un LLM (modelo de lenguaje grande) resuma en unas pocas frases la situación del juego en cada cuadro y la envíe por la red, para que el LLM del lado receptor reconstruya el cuadro a partir de ese texto. Menciona que sería difícil en tiempo real y con mucha pérdida, pero la tasa de compresión sería enorme y además encaja con la tendencia actual

  • Como ejemplo de un frame 1, muestra que podría describirse con algo como: “Estás de pie en un campo al oeste de una casa blanca cuya puerta principal está tapiada con tablas. Aquí hay un pequeño buzón”
  • Añade que si se transmiten esas descripciones usando blockchain también se podría crear un registro inmutable
  • Espera que algún día llegue una era en la que los juegos se ejecuten directamente en la computadora de cada usuario
  • Dice que la idea anterior le parece interesante

• Este enfoque de códec casi coincide exactamente con lo que quería usar en un proyecto de investigación. Como referencia, advierte que para proyectos comerciales JPEG-XS, un estándar de pago, podría ser una opción más segura porque también afirma tener latencia ultrabaja y evita problemas de patent pools (enlace1, enlace2)

  • JPEG-XS tiene como fortaleza la latencia ultrabaja, pero usa más ancho de banda. Nosotros lo usamos para streaming de imagen en tiempo real en postproducción de cine/TV (caso de uso). Usamos el encoder/decoder CUDA de IntoPIX y transmisión de baja latencia con SRT. En una red cómoda, es totalmente posible lograr una latencia total por debajo de 16 ms. Hay casos de uso con varias tasas de compresión entre centros de datos y salas de postproducción urbanas, o incluso en enlaces 1GbE entre países
  • Aclara que un patent pool no es una red de seguridad. Es como si hubiera que pagar para cruzar un puente de patentes, pero después todavía pudieran surgir otros problemas de patentes y habría que pagar más

• Comparte una entrevista (enlace) y un video demo (enlace) diciendo que el fundador de VLC está desarrollando un protocolo de streaming de latencia ultrabaja

  • Basándose en su experiencia en este campo, enfatiza que la latencia de los encoders por hardware y de H.264 es muy baja. NVENC puede codificar casi de inmediato si se desactivan funciones adicionales (predicción de múltiples cuadros, B-frames, etc.). Explica que, siempre que se eviten algoritmos de procesamiento avanzados o enfoques que exijan esperar varios cuadros, es posible codificar en menos de 10 ms justo después de terminar el renderizado en la GPU
  • Menciona que el video enlazado actualmente no se puede ver

• Reconoce que este CODEC se basa en un algoritmo similar a HTJ2K (High-Throughput JPEG 2000), y comenta que si el autor llega a ver el mensaje, sería interesante que explicara en qué se diferencia de HTJ2K

• Explica que, si uno se enfoca solo en streaming dentro de una red local, muchas funciones de los códecs modernos no hacen falta. Si se asegura un ancho de banda de unos 100 Mbps, se puede priorizar velocidad de procesamiento y baja latencia. Como ejemplo, el códec Microsoft DXT casi no tiene funciones de códecs modernos (sin codificación entrópica, compensación de movimiento ni deblocking), pero logra una compresión de 4 a 8 veces y permite decodificación por hardware, lo que ayuda a reducir la latencia total. Aun así, señala que incluso optimizando todo seguirá habiendo entre 30 y 100 ms de latencia adicional en la propia pantalla

• Comenta que el resultado del desarrollo es realmente impresionante y que espera que algún día se aplique a Moonlight o a algún proyecto similar

  • Dice que piensa lo mismo y que, si tuviera tiempo y habilidad, le habría gustado intentar añadir soporte para este códec en Moonlight por su cuenta. Menciona que, al hacer streaming por LAN con Sunshine/Moonlight de juegos como Clair Obscure, es imprescindible contar con una latencia suficientemente baja

• Citando la opinión de que este códec sigue siendo un campo poco conocido y especializado, por lo que cuesta encontrar comparaciones con códecs rivales, comenta que le interesan benchmarks frente a H.264/AVC (con opciones de zero-latency en ffmpeg) y JPEG XS. Incluso comparte ejemplos de comandos de ffmpeg y parámetros detallados de codificación