FFmpeg incorpora suporte a streaming de latência ultrabaixa com WebRTC (WHIP)

 (git.ffmpeg.org)
3 pontos por GN⁺ 2025-06-05 | 1 comentários | Compartilhar no WhatsApp
  • O avformat/whip do FFmpeg passou a incluir um muxer WHIP, permitindo lidar dentro do FFmpeg com streaming baseado em WebRTC com latência inferior a 1 segundo
  • A mudança segue a WHIP Version 3, e além do nome do muxer e da implementação, também reorganiza contextos de log e mensagens de erro de SSL, DTLS e RTC
  • Números mágicos internos da implementação foram substituídos por macros e funções, e também foram refinados a lista de curvas DTLS, o profile SRTP, os números mágicos ICE STUN e o tratamento de RTP payload type
  • No caminho de mídia, em vez de tamanho de frame fixo, passa a ser usado rtc->audio_par->frame_size, e para conversão de entradas MP4/ISOM para Annex B é usado h264_mp4toannexb
  • A configuração de build foi alterada para que whip seja ativado apenas quando DTLS estiver habilitado, e no momento o suporte está limitado ao OpenSSL

Adição do muxer WHIP e integração ao build

Organização do tratamento de DTLS, ICE e RTP

  • O muxer WHIP teve a implementação refinada junto com a mudança de nome, e as mensagens de erro e os contextos de log de SSL, DTLS e RTC foram melhorados
  • Os números mágicos foram substituídos por macros, e parte da lógica foi separada em funções
    • Os níveis de log também foram ajustados de forma mais clara
  • No caminho de DTLS, foram incluídas várias mudanças relacionadas a compatibilidade e desempenho
    • A lista de curvas DTLS foi atualizada
    • Os nomes de profile SRTP para FFmpeg e OpenSSL foram refinados
    • O handshake DTLS e o tratamento de ICE foram otimizados para melhorar o desempenho
    • Foi adotado um único timeout de handshake e o papel de servidor para evitar ARQ
  • O tratamento de ICE foi reorganizado para unificar request/response e o handshake DTLS em uma única função
    • Os números mágicos de ICE STUN foram refinados
  • O RTP payload type foi atualizado com base na definição do Chrome

Processamento de mídia e restrição ao OpenSSL

  • No áudio, o tamanho de frame fixo foi substituído pelo uso de rtc->audio_par->frame_size
  • Para converter entradas MP4/ISOM em Annex B, é usado h264_mp4toannexb
  • O problema de timestamp do OPUS e a configuração de marker após o uso de BSF também foram corrigidos
  • As implementações de TLS e DTLS foram unificadas em uma estrutura comum
    • BIO callback, read, write, print_ssl_error, openssl_init_ca_key_cert e init_bio_method passaram a ser compartilhados
    • A mesma estrutura de dados é usada
  • Erros de build com OpenSSL foram corrigidos para funcionar com o Pion
  • O configure foi alterado para ativar whip apenas quando dtls estiver habilitado
    • No momento, o suporte é limitado ao OpenSSL

Leituras relacionadas

1 comentários

 
GN⁺ 2025-06-05
Opiniões no Hacker News

  • Estou realmente animado com a transmissão via WebRTC. Deixei os motivos organizados no README do Broadcast Box e no PR do OBS
    Agora que GStreamer, OBS e FFmpeg todos têm suporte a WHIP, temos de fato um protocolo universal de transmissão de vídeo que pode ser usado em todas as plataformas: mobile, web, embarcados, software de broadcast etc.
    Venho trabalhando há anos com open source e transmissão via WebRTC, e vejo isso como um grande marco
    [0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
    [1] https://github.com/obsproject/obs-studio/pull/7926

    • Do ponto de vista de quem trabalha com transmissão de eventos, essa mudança pode fazer do OBS uma alternativa realista a softwares profissionais como o vMix. Especialmente o suporte a P2P e a capacidade de transmitir várias cenas parecem muito valiosos
    • Fico curioso se existe algum player de vídeo capaz de reproduzir streams WebRTC. Da última vez que verifiquei, VLC e outras ferramentas populares ainda não davam suporte

  • Não é a parte de SCTP. Na prática, o que foi implementado é o WebRTC-HTTP Ingestion Protocol, ou WHIP, um protocolo HTTP de baixa latência para se conectar a um gateway que se comunica com o peer por meio do protocolo baseado em SCTP do WebRTC
    https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
    Espero que um dia possamos migrar para um protocolo P2P baseado em QUIC ou WebTransport em vez de SCTP. QUIC lida bem com o que o SCTP fazia sobre o UDP existente, sem aumentar muito a complexidade nem as diferenças de implementação
    Um dos candidatos é o Media-over-QUIC (MoQ), mas não há QUIC P2P nos navegadores, e o progresso nessa área parece parado há alguns anos
    https://quic.video/ https://datatracker.ietf.org/group/moq/about/

    • Fico curioso sobre qual seria a melhor forma de expor e usar a parte de SCTP. O rascunho da IETF sobre WHIP não parece ter nenhuma menção ou proposta sobre isso
      A maioria dos provedores de WHIP também dá suporte a DataChannel, mas isso ainda não está padronizado

  • Fico curioso sobre o que isso significa. Quer dizer que um site pode se conectar diretamente a uma instância do FFmpeg e receber streams de áudio ou vídeo?
    A explicação da Phoronix é um pouco mais detalhada: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

    • Parece significar que programas que usam as bibliotecas do FFmpeg, especialmente a libavformat, poderão receber streams WebRTC

  • Isso deve tornar muito mais fácil criar streams auto-hospedados ou uma CDN de streaming
    O FFmpeg é um software de mídia independente e plug-and-play realmente incrível quando você sabe usá-lo

    • Estou muito animado. Especialmente se houver Simulcast, dá para tornar isso muito barato e fácil para as pessoas
      Criei o https://github.com/Glimesh/broadcast-box porque queria facilitar muito a auto-hospedagem e o uso de WebRTC
    • LLMs conhecem muito bem como usar o FFmpeg. Para praticamente qualquer tarefa relacionada a vídeo que você pergunte, eles geram uma linha de comando ffmpeg adequada
    • É bem isso, e este quadrinho sempre me vem à cabeça: https://xkcd.com/2347/

  • O Gajim, cliente XMPP, esperava por isso há muito tempo. O recurso de chamadas de áudio/vídeo estava basicamente abandonado, e eles estavam esperando pacientemente que o FFmpeg tornasse mais fácil adicioná-lo de volta

    • Fico curioso se Gajim e XMPP ainda são usados. Sinto falta da época em que usávamos apps de chat via pidgin como antigamente
      Agora tudo virou jardim murado ou serviço específico de cada app

  • É agradável ver o gráfico do Anubis inesperadamente. Até agora já o vi no ffmpeg, no gnu e em outros lugares

    • Eu também gosto, mas desta vez ele não me deixa entrar

  • Espero que isso não torne mais perigoso ter ffmpeg no sistema. Vulnerabilidades de segurança em WebRTC são causa de muitos incidentes de invasão, e é uma das primeiras coisas que desativo ao instalar um navegador

    • Fico curioso sobre quais vulnerabilidades de segurança você está falando
      Esta implementação é muito pequena, e tenho 100% de certeza de que ela oferece ao usuário o melhor possível
    • Como o ffmpeg é código de alta performance em C que lida com codecs obscuros e formatos binários, não parece haver motivo para se preocupar apenas com WebRTC
    • Fico curioso se é possível remover isso do build com um argumento como --without-whip caso a pessoa não queira ou não precise. Isso seria o ideal
    • O ffmpeg já teve muitos problemas de segurança no passado [1], então, ao lidar com entrada de usuário, isolá-lo bem já é uma boa prática de qualquer forma
      Uma boa abordagem é criar uma imagem Docker contendo apenas o ffmpeg e suas dependências, e executar docker run para cada tarefa de conversão. Se também for preciso gerar miniaturas de imagens ou documentos, dá para incluir ClamAV, OpenOffice e ImageMagick
      Pessoalmente, acho melhor colocar servidores que fazem algo além de simplesmente receber e servir arquivos gerados por usuários em uma VLAN separada e fortemente bloqueada; na AWS, dentro de um Security Group
      Isso não é uma crítica ignorante aos projetos mencionados. Segurança é difícil, especialmente ao lidar com formatos binários acumulados ao longo de muito tempo e às vezes submetidos a engenharia reversa de maneiras duvidosas. É mais sensato reconhecer isso antes de ser pego, como o 4chan
      [1] https://ffmpeg.org/security.html

  • Muito bom. Estou criando um controle remoto baseado na web, e ficaria muito satisfeito se isso permitisse transformar ffmpeg gdigrab em um stream WebRTC e fazer o cliente consumi-lo diretamente, sem a gambiarra com ExpressJS que estou fazendo agora

  • É interessante que eu continue sendo bloqueado pela detecção de bots no iOS Safari. Acontece tanto no Wi-Fi da empresa quanto nos dados móveis
    Queria que o Anubis me deixasse passar

    • Fico curioso se aparece uma página de "access denied" ou se o desafio fica se repetindo infinitamente
    • Fico curioso se você está usando uma rede dual-stack

  • O Anubis não me deixa passar ;(