Projetei meu próprio codec de vídeo PyroWave para streaming de jogos absurdamente rápido

• Streaming de jogos exige latência extremamente baixa
• O PyroWave alcança velocidade extrema ao eliminar predição de movimento e codificação entrópica
• A abordagem baseada em transformada wavelet discreta (DWT) o diferencia dos codecs tradicionais baseados em DCT
• Com processamento paralelo em blocos de 32×32 e implementação rápida de controle de taxa, a codificação/decodificação na GPU é extremamente veloz
• Na avaliação de qualidade, ele mostrou resultados suficientes em certos cenários mesmo quando comparado a H.264/HEVC/AV1

---

Exigências de latência ultrabaixa no streaming de jogos e os limites dos métodos atuais

• Com o aumento recente da demanda por streaming de gameplay, a transmissão em tempo real pela rede de um dispositivo para outro se tornou importante
• Da DMA, renderização, codificação, transmissão e decodificação até a saída na tela, a latência acumulada em cada etapa impacta fortemente a experiência geral
• A solução tradicional é usar codecs de vídeo com aceleração por GPU como H.264, HEVC e AV1
• Mas, no streaming, não é possível usar técnicas de alta compressão como B-frames, o que torna severas as restrições de latência e bitrate

Filosofia de projeto: eliminar predição de movimento e codificação entrópica

Remoção da predição de movimento – abordagem Intra-Only

• A predição de movimento dos codecs de vídeo convencionais foi removida, tratando todos os frames de forma independente
• Como resultado, o bitrate aumenta, mas há vantagens em resiliência a erros, simplicidade e consistência de qualidade
• Já existe experiência de uso da abordagem Intra-only em áreas como o cinema digital
• Com isso, ela não é adequada para streaming pela internet, mas pode ter bons resultados em ambientes de alta largura de banda, como LAN

Remoção da codificação entrópica

• A codificação entrópica foi totalmente excluída por ser desfavorável ao processamento paralelo em GPU
• Um campo antes restrito a ASICs dedicados ou equipamentos especiais foi viabilizado em software
• Abre espaço para a área de codecs ultrabaixa latência que não existem no FFmpeg

Uma nova abordagem com transformada wavelet (DWT)

• Em vez da DCT dos codecs tradicionais, foi adotada a transformada wavelet discreta (DWT)
• A transformada wavelet é semelhante à estrutura de mip-map, familiar para programadores gráficos
• A imagem é separada em várias bandas, e aplica-se quantização a cada uma delas
• As bandas de alta frequência são quantizadas de forma mais agressiva para aproveitar ao máximo as características visuais
• Esse processo também se conecta ao controle de taxa (rate control)

Principais artefatos e limitações de codecs baseados em wavelet

• Em vez dos artefatos de blocking do JPEG, wavelets tendem a gerar principalmente borramento ou ringing
• Isso pode não ser um grande problema na prática, pois se sobrepõe ao efeito de blur causado por TAA em jogos recentes

Empacotamento rápido do bitstream e paralelização

• Blocos de coeficientes de 32×32 são processados de forma independente, limitando o impacto de perda de pacotes a apenas borramento localizado
• A composição em subblocos 8×8 e 4×2 otimiza o processamento paralelo por unidade de workgroup da GPU
• Usa codificação por bitplane, mas armazena os dados brutos de bits sem codificação entrópica complexa
• Métodos amigáveis à GPU, como armazenamento SSBO de 8 bits, maximizam a eficiência de memória e a velocidade de processamento

Controle de taxa preciso e rápido

• Diferentemente dos métodos tradicionais com codificação entrópica, a taxa é ajustada repetindo a medição/armazenamento do número de bits omitidos por bloco
• O codec cumpre rigorosamente o CBR ao calcular globalmente a faixa ótima de taxa-distorção
• A vantagem típica dos codecs wavelet, o encerramento antecipado por bitplane, também é alcançada em software

Desempenho e eficiência na prática

• Em 1080p 4:2:0, a codificação/decodificação é concluída em 0,13 ms na GPU RX 9070 XT
• Em cada etapa do processamento, como DWT e quantização, otimizações com FP16 são usadas para ajustar o trade-off entre qualidade e velocidade
• Experimentos também confirmaram que, até com vídeo 4K, comprimir na GPU e depois transmitir é mais rápido do que a velocidade de transferência via PCI-e
• Foi alcançada uma velocidade mais de 10 vezes superior até mesmo à de codecs de hardware dedicados

Avaliação de qualidade e comparação com outros codecs

• Grupo de comparação: codificadores de GPU do FFmpeg (H.264/HEVC/AV1) em modo Intra-only, CBR e latência mínima
• Com 200 Mbps e 60 fps, os artefatos de compressão do PyroWave são quase indistinguíveis a olho nu
• Em várias cenas de jogos, ele também obteve resultados suficientes em métricas objetivas de qualidade como VMAF, SSIM e PSNR
• Certas métricas (como VMAF) tendem a favorecer um pouco o PyroWave, enquanto PSNR e afins expõem o impacto da precisão interna
• Embora existam borramento e artefatos de menor qualidade na imagem, isso não representa um grande problema prático considerando os visuais dos jogos modernos e o objetivo de uso

Conclusão

• O PyroWave apresenta uma alternativa inovadora para streaming local de jogos que exige latência extremamente baixa e processamento em alta velocidade
• Ele é especialmente adequado ao processamento paralelo e ao controle de CBR em sintonia com arquiteturas modernas de GPU
• Apesar de ser um projeto pessoal, o nível de satisfação é alto como solução DIY de streaming ultrarrápido

[GN⁺]

Comentários do Hacker News

• Fala sobre o VC-2, um codec intra baseado em wavelets e de latência ultrabaixa desenvolvido pela BBC. Esse codec pode ser usado sem royalties e, por enquanto, só existem implementações baseadas em CPU no ffmpeg e no repositório oficial da BBC. A pessoa pretende criar uma versão acelerada por CUDA como dissertação de mestrado. As implementações em Vulkan feitas no GSoC do ano passado ainda não são satisfatórias. Recomenda fortemente que as pessoas deem uma olhada nesse codec

  • Pergunta se poderia explicar com mais detalhes por que a implementação em Vulkan é insuficiente. Diz que não é uma crítica, mas uma curiosidade genuína
  • Pergunta sobre a experiência em relação à diferença de qualidade de imagem entre VC-2 e JPEG XS. Menciona que, em geral, ouviu dizer que o JPEG XS oferece qualidade visual mais alta, mas quer saber como isso se sente no uso real

• Este texto é um excelente exemplo de como explicar bem a correspondência entre tolerância à distorção e trade-offs adequados às características do sinal. Mesmo se você estiver na posição de escolher um codec em vez de projetar um, seguir esse processo pode levar a bons resultados. Se você tem interesse em áreas onde latência extremamente baixa é importante, vale consultar o relatório da VSF que resume as características de vários codecs alternativos (link)

• Eu quase não sei nada sobre codificação de vídeo, mas acho que haveria muitas abordagens práticas ainda não exploradas em streaming de videogame se o encoder cooperasse minimamente com a game engine. Por exemplo, a maioria dos motores de renderização já tem buffers de previsão de movimento para seus próprios usos, e isso poderia ser aproveitado de graça também na codificação. Mas lamenta que provavelmente existam patentes que bloqueiem esse tipo de invenção, o que dificultaria colocá-la em prática

  • Enfatiza que os “motion vectors” do H.264 são apenas uma técnica de compressão de imagem em nível de bits, e não a mesma coisa que os vetores de movimento usados em jogos 3D reais. Nos jogos 3D, os vetores de movimento representam a variação de posição dos objetos no espaço 3D; no H.264, o método consiste em copiar blocos de pixels de algum frame anterior arbitrário e codificar a diferença no estilo JPEG. Explica que é por causa dessa cópia de blocos que, quando falta largura de banda, o vídeo em H.264 parece quebrado em pedaços quadrados
  • Usa como exemplo um jogo FPS com 2 frames de latência de rede e diz que, se a game engine fornecer a UI e a visão do mundo 3D em framebuffers separados, o cliente poderia deslocar antecipadamente só a visão do mundo no frame anterior recebido do servidor assim que recebesse a entrada do mouse. Jogos de VR já compensam atraso de entrada desse jeito. Não é perfeito, mas faz uma grande diferença, e até a paralaxe poderia ser simulada em certa medida se fosse usado um mapa de profundidade
  • Assim como em codificação de vídeo baseada em sensores, seria possível usar informações do acelerômetro ou da bússola digital do celular para dar dicas à codificação (link). No caso de jogos 2D, seria possível fornecer com precisão os vetores de movimento do fundo e de grandes objetos em primeiro plano. Elementos 2D como overlays, HUD, placares e legendas poderiam ser enviados com um método de compressão separado para aumentar a nitidez dos pixels. Diz que ficou surpreso com o fato de haver tanta gente cética em relação a essas ideias no HN
  • Eu também sempre me perguntei isso. Acho que o cliente poderia fazer pelo menos um pouco de composição por conta própria. Por exemplo, renderizar fundo e primeiro plano em ritmos diferentes, ou usar um codec nítido para o HUD de acordo com a prioridade. Sempre me surpreendeu que o Stadia, mesmo tendo jogos próprios, ainda funcionasse como simples streaming de vídeo. Talvez tenham testado várias abordagens, mas não obtiveram ganho suficiente em comparação com codecs de vídeo convencionais
  • Em um jogo 2D com sprites, seria fácil fornecer ao encoder vetores de movimento muito precisos. Em jogos com renderização 3D, não tenho certeza se converter vetores de movimento de objetos 3D para algo adequado à codificação 2D realmente ajudaria na prática

• Propõe uma abordagem em que um LLM (modelo de linguagem grande) resume a situação do jogo a cada frame em algumas frases e envia isso pela rede, e o LLM do lado receptor reconstrói o frame a partir desse texto. Menciona que isso seria difícil em tempo real e muito sujeito a perdas, mas a taxa de compressão seria enorme e a ideia combina com a tendência atual

  • Como exemplo para o frame 1, mostra que algo como “Você está em um campo a oeste, e a porta da frente da casa branca está bloqueada com tábuas. Há uma pequena caixa de correio aqui” poderia descrever a cena
  • Acrescenta que, usando blockchain para transmitir essas descrições, também seria possível criar um registro imutável
  • Diz esperar que um dia os jogos possam voltar a ser executados diretamente no computador de cada usuário
  • Diz que a ideia acima é interessante

• Esse método de codec é quase exatamente o que eu queria usar em um projeto de pesquisa. Como referência, informa que, em projetos comerciais, por causa de questões de pool de patentes, o padrão pago JPEG-XS (link1, link2) também afirma oferecer latência ultrabaixa e pode ser uma escolha mais segura

  • O JPEG-XS tem como ponto forte a latência ultrabaixa, mas usa mais largura de banda. Nós o usamos em streaming de imagem em tempo real para pós-produção de cinema/TV (caso de uso). Usamos encoder/decoder CUDA da IntoPIX e transporte SRT de baixa latência. Em uma rede confortável, é perfeitamente possível ficar abaixo de 16 ms de latência total. Há casos de uso com várias taxas de compressão entre datacenters e estúdios de pós-produção em áreas urbanas, ou até entre países em links 1GbE
  • Esclarece que pool de patentes não é uma rede de segurança. Explica que é como pagar para atravessar uma ponte de patentes, mas ainda assim depois poder esbarrar em outro problema de patente e ter de pagar de novo

• Compartilha uma entrevista (link) e um vídeo de demonstração (link), dizendo que o fundador do VLC está desenvolvendo um protocolo de streaming de latência ultrabaixa

  • Com base na própria experiência na área, enfatiza que a latência de encoders de hardware e do H.264 é muito baixa. O NVENC consegue codificar quase instantaneamente se recursos extras (previsão de múltiplos frames, B-frames etc.) forem desativados. Explica que, desde que se evitem algoritmos de processamento avançado ou métodos que exijam esperar vários frames, é possível codificar em menos de 10 ms logo após o fim da renderização na GPU
  • Menciona que o vídeo do link atualmente não está disponível

• Observa que esse CODEC é baseado em um algoritmo semelhante ao HTJ2K (High-Throughput JPEG 2000) e comenta que, se o autor vir isso, seria interessante explicar as diferenças em relação ao HTJ2K

• Explica que, se o foco for apenas streaming em rede local, muitos recursos dos codecs modernos não são necessários. Se houver algo como 100 Mbps de largura de banda disponível, é possível priorizar velocidade de processamento e baixa latência. Como exemplo, menciona o codec Microsoft DXT, que quase não tem recursos de codecs modernos (sem codificação entrópica, compensação de movimento nem deblocking), mas permite compressão de 4 a 8 vezes e decodificação por hardware, o que ajuda a reduzir a latência total. Porém, aponta que, mesmo com otimização, o próprio display ainda adiciona de 30 a 100 ms de atraso

• Diz que o resultado do desenvolvimento é realmente impressionante e espera que um dia isso seja aplicado ao Moonlight ou a projetos semelhantes

  • Diz que pensa a mesma coisa e que, se tivesse tempo e habilidade, gostaria de tentar adicionar suporte a esse codec no Moonlight por conta própria. Menciona que, ao fazer streaming em LAN com Sunshine/Moonlight de jogos como Clair Obscure, é realmente necessário ter latência suficientemente baixa

• Citando a opinião de que esse codec ainda é um campo pouco familiar e especializado, tornando difícil encontrar materiais comparativos com codecs concorrentes, diz ter curiosidade sobre benchmarks contra H.264/AVC (com opção de latência zero no ffmpeg) e JPEG XS. Também compartilha exemplos de comandos do ffmpeg e parâmetros detalhados de codificação