FFmpeg integra soporte de streaming de latencia ultrabaja con WebRTC (WHIP)

 (git.ffmpeg.org)
3 puntos por GN⁺ 2025-06-05 | 1 comentarios | Compartir por WhatsApp
  • Se añadió un muxer WHIP a avformat/whip, lo que permite manejar dentro de FFmpeg streaming basado en WebRTC con menos de 1 segundo de latencia
  • El cambio se basa en WHIP Version 3, y además del nombre del muxer y su implementación, también se reorganizaron los contextos de logs y mensajes de error de SSL, DTLS y RTC
  • Los números mágicos internos de la implementación fueron reemplazados por macros y funciones, y también se pulieron la lista de curvas de DTLS, el perfil SRTP, los números mágicos de ICE STUN y el manejo del RTP payload type
  • En la ruta de medios, en lugar de un tamaño de frame fijo ahora se usa rtc->audio_par->frame_size, y para convertir entradas MP4/ISOM a Annex B se utiliza h264_mp4toannexb
  • La configuración de compilación cambió para que whip se habilite solo cuando DTLS está activado, y por ahora el soporte está limitado a OpenSSL

Adición del muxer WHIP y conexión con la compilación

Reorganización del manejo de DTLS, ICE y RTP

  • El muxer WHIP fue refinado junto con el cambio de nombre, y se mejoraron los mensajes de error y los contextos de logs de SSL, DTLS y RTC
  • Los números mágicos fueron reemplazados por macros y parte de la lógica se separó en funciones
    • También se ajustaron los niveles de log para que sean más claros
  • En la ruta de DTLS se incorporaron varios cambios relacionados con compatibilidad y rendimiento
    • Se actualizó la lista de curvas de DTLS
    • Se ajustaron los nombres de los perfiles SRTP para FFmpeg y OpenSSL
    • Se optimizaron el DTLS handshake y el manejo de ICE para mejorar el rendimiento
    • Se evita ARQ usando un único handshake timeout y el rol de servidor
  • El manejo de ICE se reorganizó para unificar request/response y el DTLS handshake dentro de una sola función
    • También se ajustaron los números mágicos de ICE STUN
  • El RTP payload type se actualizó tomando como referencia la definición de Chrome

Procesamiento de medios y restricción a OpenSSL

  • En audio, el tamaño de frame fijo fue reemplazado por el uso de rtc->audio_par->frame_size
  • Para convertir entradas MP4/ISOM a Annex B se usa h264_mp4toannexb
  • También se corrigieron el problema de timestamp de OPUS y la configuración de marker después de usar BSF
  • Las implementaciones de TLS y DTLS se unificaron bajo una estructura común
    • Se comparten BIO callback, read, write, print_ssl_error, openssl_init_ca_key_cert e init_bio_method
    • Se usa la misma estructura de datos
  • Se corrigieron errores de compilación con OpenSSL para que funcione con Pion
  • configure se cambió para habilitar whip solo cuando dtls está activado
    • Actualmente el soporte es solo para OpenSSL

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-06-05
Opiniones de Hacker News

  • Tengo muchas ganas de ver broadcasting con WebRTC. Dejé resumidas las razones en el README de Broadcast Box y en el PR de OBS
    Ahora que GStreamer, OBS y FFmpeg soportan WHIP, básicamente tenemos un protocolo universal de transmisión de video que se puede usar en todas las plataformas: móviles, web, embebidos, software de broadcast, etc.
    Llevo años trabajando en open source y broadcasting con WebRTC, y lo veo como un gran hito
    [0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
    [1] https://github.com/obsproject/obs-studio/pull/7926

    • Desde mi posición trabajando en el área de transmisiones de eventos, este cambio puede convertir a OBS en una alternativa realista a software profesional como vMix. En especial, el soporte P2P y la capacidad de transmitir varias escenas parecen muy valiosos
    • Me pregunto si existe algún reproductor de video que pueda reproducir streams WebRTC. La última vez que revisé, VLC y otras herramientas populares todavía no lo soportaban

  • No se trata de la parte de SCTP. En realidad implementa WebRTC-HTTP Ingestion Protocol, es decir WHIP, un protocolo HTTP de baja latencia para conectarse a un gateway que se comunica con los peers mediante el protocolo basado en SCTP de WebRTC
    https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
    Ojalá algún día podamos pasar de SCTP a un protocolo P2P basado en QUIC o WebTransport. QUIC maneja bien, sobre UDP existente, lo que hacía SCTP, sin aumentar mucho la complejidad ni las diferencias entre implementaciones
    Uno de los candidatos es Media-over-QUIC (MoQ), pero los navegadores no tienen QUIC P2P y el avance por ese lado está detenido desde hace años
    https://quic.video/ https://datatracker.ietf.org/group/moq/about/

    • Me pregunto cómo convendría exponer y usar la parte de SCTP. El borrador IETF de WHIP no parece mencionarlo ni proponer nada al respecto
      La mayoría de los proveedores de WHIP también soportan DataChannel, pero todavía no está estandarizado

  • Me pregunto qué significa esto. ¿Quiere decir que un sitio web puede conectarse directamente a una instancia de FFmpeg para recibir un stream de audio o video?
    La explicación de Phoronix es un poco más detallada: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

    • Parece significar que los programas que usan las bibliotecas de FFmpeg, en especial libavformat, podrán recibir streams WebRTC

  • Con esto parece que será mucho más fácil crear streams autoalojados o una CDN de streaming
    FFmpeg, si sabes usarlo, es un software multimedia independiente y plug-and-play realmente sorprendente

    • Me entusiasma mucho. Sobre todo si también incluye Simulcast, podría ofrecerse a la gente de forma muy barata y sencilla
      Creé https://github.com/Glimesh/broadcast-box porque quería hacer mucho más fáciles el autoalojamiento y WebRTC
    • Los LLM conocen muy bien cómo usar FFmpeg. Puedes preguntarles casi cualquier tarea relacionada con video y te generan el comando de una línea de ffmpeg correspondiente
    • Totalmente, y siempre me viene a la mente esta historieta: https://xkcd.com/2347/

  • Gajim, el cliente XMPP, llevaba mucho tiempo esperando esto. Su función de llamadas de audio/video estaba prácticamente abandonada, y venía esperando con paciencia que gracias a FFmpeg fuera más fácil volver a agregarla

    • Me pregunto si todavía se usan Gajim y XMPP. Extraño los tiempos en que usábamos apps de chat con pidgin como antes
      Ahora todo son jardines cerrados o servicios separados por app

  • Da gusto encontrarse inesperadamente con el gráfico de Anubis. Hasta ahora lo he visto en ffmpeg, gnu y otros

    • A mí también me gusta, pero esta vez no me deja entrar

  • Espero que esto no haga más peligroso tener ffmpeg en el sistema. Las vulnerabilidades de seguridad de WebRTC son causa de muchos incidentes de intrusión, y es una de las primeras funciones que desactivo cuando instalo un navegador

    • Me pregunto a qué vulnerabilidades de seguridad te refieres
      Esta implementación es muy pequeña, y estoy 100% seguro de que ofrece al usuario lo mejor posible
    • ffmpeg es código de alto rendimiento en C que maneja códecs y formatos binarios esotéricos, así que no parece necesario preocuparse solo por WebRTC
    • Me pregunto si, si no lo quieres o no lo necesitas, se puede excluir de la compilación con un argumento como --without-whip. Eso sería ideal
    • ffmpeg ya tuvo muchos problemas de seguridad en el pasado [1], así que al manejar entradas de usuarios, aislarlo bien es una buena práctica de todos modos
      Conviene crear una imagen Docker que incluya solo ffmpeg y sus dependencias, y ejecutar docker run para cada tarea de conversión. Si también hay que generar miniaturas de imágenes o documentos, se pueden incluir ClamAV, OpenOffice e ImageMagick
      Personalmente, creo que cualquier servidor que haga algo más que simplemente recibir y servir archivos generados por usuarios debería estar en una VLAN separada y muy restringida, o si es en AWS, dentro de un Security Group
      Esto no es una crítica ignorante a los proyectos mencionados. La seguridad es difícil, sobre todo cuando se manejan formatos binarios acumulados durante mucho tiempo y a veces retroingenierizados de formas dudosas. Es más sensato reconocerlo antes de terminar como 4chan
      [1] https://ffmpeg.org/security.html

  • Muy bueno. Estoy creando un control remoto basado en web, y si con esto puedo convertir ffmpeg gdigrab en un stream WebRTC para que el cliente lo consuma directamente, sin el trabajo de rodeo con ExpressJS que hago ahora, sería muy satisfactorio

  • Es interesante que en iOS Safari me siga bloqueando la detección de bots. Me pasa tanto con el WiFi de la empresa como con datos móviles
    Ojalá Anubis me dejara pasar

    • Me pregunto si aparece la página de "access denied" o si el desafío se repite infinitamente
    • Me pregunto si estás usando una red dual stack

  • Anubis no me deja pasar ;(