FFmpeg faz merge de suporte a streaming de ultra baixa latência com WebRTC (WHIP)

• O FFmpeg agora adiciona oficialmente um muxer WHIP (WebRTC-HTTP Ingestion Protocol), com suporte direto a streaming de ultra baixa latência abaixo de 1 segundo
• Neste commit, a nomenclatura e a estrutura do muxer WHIP foram reorganizadas, e as mensagens de erro e logs de SSL/DTLS/RTC foram aprimorados
• Parâmetros centrais de protocolo, como curvas/perfis DTLS, payload RTP e ICE STUN, foram atualizados para corresponder às definições do Chrome, e os magic numbers foram extraídos para macros e funções
• O handshake DTLS e o processamento de ICE foram integrados e otimizados em uma única função, melhorando bastante desempenho e estabilidade
• Foram corrigidos bugs de transcodificação de áudio e vídeo (h264_mp4toannexb, timestamp de OPUS, configuração de marcador etc.), aumentando a compatibilidade com ambientes WebRTC padrão
• A dependência de OpenSSL foi explicitada com mais clareza, de modo que o WHIP só é compilado quando há suporte a DTLS
• Com apenas o FFmpeg, fica mais fácil montar um ambiente de transmissão e streaming em tempo real baseado em WebRTC, aproveitando a característica de ultra baixa latência em comparação com protocolos legados como RTMP

---

avformat/whip: adicionado suporte ao muxer WHIP no FFmpeg

Resumo das principais mudanças

• Introdução oficial de um muxer baseado no WHIP Version 3, com reorganização da nomenclatura e da estrutura interna
• O contexto de logs e as mensagens de erro de SSL, DTLS e RTC ficaram bem mais claros
• Magic numbers antes hardcoded foram extraídos para macros e funções separadas, melhorando a manutenção
• Itens como a lista de curvas DTLS e nomes de perfis SRTP foram ajustados para seguir os padrões do FFmpeg e do OpenSSL
• O magic number do ICE STUN e os tipos de payload RTP foram atualizados para ficar alinhados ao padrão do navegador Chrome
• Foram resolvidos problemas no processamento de mídia, como tamanho de frame de áudio, conversão H.264 MP4→AnnexB e timestamp de OPUS
• A lógica de handshake DTLS e processamento de ICE foi unificada em uma única função, facilitando a manutenção
• As condições para suporte a DTLS baseado em OpenSSL ficaram mais claras, melhorando erros de build e compatibilidade
• Houve integração da estrutura interna de TLS/DTLS, incluindo SRTP, callbacks BIO e inicialização de chave/ certificado de CA
• Foram alterados e adicionados 13 arquivos no total, incluindo a criação do arquivo whip.c

Contexto e importância

• WHIP é um protocolo padrão baseado em HTTP para envio de streams com WebRTC, sendo essencial para transmissões ao vivo com ultra baixa latência
• Até agora, codificar e transmitir via WebRTC no FFmpeg exigia ferramentas separadas ou uma intermediação complexa, mas com este merge passa a ser possível fazer ingest via WHIP com um único comando do FFmpeg
• Isso marca um ponto de virada técnico para integração direta com o ecossistema WebRTC moderno em áreas como transmissão em tempo real, live commerce e videoconferência

[GN⁺]

Opiniões do Hacker News

• Estou extremamente animado com transmissão via WebRTC; no README do Broadcast Box e no PR do OBS link explico por que penso assim. Agora que GStreamer, OBS e FFmpeg todos passam a oferecer suporte a WHIP, chegamos a um protocolo universal de transmissão de vídeo aplicável a todas as plataformas. Com anos de experiência trabalhando com open source + transmissão via WebRTC, vejo este resultado como um grande marco.
  • Eu jogava jogos remotos de dosbox no celular via VNC, mas agora estou com vontade de criar eu mesmo um webapp de input handler e gastar tempo infinitamente em um novo desafio com essa tecnologia + OBS.
  • Pergunta se há planos de adicionar a uma unidade móvel de streaming a função de multipath/failover-bonding conectando vários modems 5G, por exemplo adaptando SRT para transmitir H.265 por vários links.
  • Impressionado com o broadcast-box e com as contribuições de desenvolvimento após usar isso diretamente em várias plataformas, como software de transmissão popular, mobile, web e embarcados.
  • Expressa alegria ao ver sua biblioteca de webrtc sendo útil em vários projetos e influenciando um amplo espectro tecnológico.
• Informa a implementação do WebRTC-HTTP Ingestion Protocol (WHIP) — não se trata de lidar com SCTP em si, mas de um gateway via HTTP para peers que usam WebRTC; recomenda consultar o documento WHIP IDF da IETF (link). Espera que algum dia haja migração de SCTP para um protocolo p2p baseado em QUIC ou WebTransport. Diz ter interesse em Media-over-Quic (MoQ), mas compartilha que o suporte em navegadores e a evolução estão lentos há anos. Links relacionados: quic.video e MoQ IETF introduction.
  • Pergunta de que forma se gostaria de usar/expor a parte de SCTP; como não há menção ou proposta relacionada no rascunho IETF do WHIP, a questão fica ambígua. A maioria dos "WHIP Providers" suporta DataChannel, mas isso não está padronizado.
• Pergunta se, com uma conexão direta entre o FFmpeg e um site, já é possível receber streams de áudio/vídeo imediatamente; mais detalhes podem ser vistos na página do Phoronix (link).
  • Explicação resumida de que programas que usam as bibliotecas do FFmpeg (especialmente libavformat) poderão receber e aproveitar streams WebRTC diretamente.
• Expectativa de que essa mudança torne muito mais fácil montar streaming self-hosted / uma CDN de streaming, destacando a independência e a característica plug and play do ffmpeg.
  • Em combinação com Simulcast, a perspectiva é de reduzir drasticamente custos e barreiras de entrada; um dos motivos para criar o broadcast-box foi justamente diminuir a barreira de entrada de self-hosting + WebRTC.
  • Com uso de LLM, é possível até chegar a comandos one-liner para todo tipo de tarefa de vídeo relacionada ao ffmpeg; grande elogio à experiência de uso de IA.
  • Sempre vem à mente a tirinha xkcd 2347, que mostra de forma perfeita a versatilidade do ffmpeg.
• Foi marcante encontrar a arte gráfica do Anubis de forma inesperada em ffmpeg, gnu etc.
• Preocupação de que adicionar o recurso WHIP possa tornar mais arriscado manter ffmpeg no sistema; sente que vulnerabilidades de segurança de WebRTC são uma causa real de muitos incidentes e relata que no passado sempre desativava isso após instalar navegadores.
  • Pergunta quais vulnerabilidades de segurança existem, mencionando forte convicção de que esta implementação é muito pequena e oferece o melhor resultado possível ao usuário.
  • Pergunta se existe uma opção como --without-whip para remover isso totalmente do build se não for desejado, opinando que isso seria ideal.
  • Como o ffmpeg já teve muitos problemas de segurança no passado, ao processar entrada de usuário o ideal continua sendo usar sempre um ambiente isolado; por exemplo, subir uma imagem Docker nova a cada tarefa contendo apenas ffmpeg e suas dependências, ou, se também for preciso lidar com miniaturas ou documentos, recomendar adicionar ClamAV, OpenOffice, ImageMagick etc. Também recomenda operar servidores que tratam arquivos gerados por usuários em uma VLAN o mais isolada possível ou, na AWS, apenas dentro de security groups. Enfatiza que não é uma crítica a cada projeto, mas sim a dificuldade inerente de formatos binários e a importância de medidas preventivas de segurança. Também cita o caso do 4chan; a página de segurança do ffmpeg está aqui.
• Pergunta como andam as atividades de auditoria de segurança do ffmpeg, compartilhando a impressão de que no site oficial isso parece um tanto reativo.
• Pergunta se agora será possível gravar com ffmpeg o stream de áudio de uma videoconferência do Jitsi.
• Pergunta se alguém conseguiu aplicar com sucesso o suporte a whip ao compilar o FFmpeg a partir do código-fonte, relatando dificuldade em encontrar as opções corretas de ./configure.
  • A orientação é que as opções necessárias são --enable-muxer=whip e --enable-openssl.
• Está contando os dias para esse recurso chegar ao Jellyfin.
  • Em resposta, perguntam que benefício funcional isso traria ao Jellyfin.