FFmpeg integra soporte para streaming de ultra baja latencia con WebRTC (WHIP)

• Se añadió oficialmente a FFmpeg un muxer WHIP (WebRTC-HTTP Ingestion Protocol), con soporte directo para streaming de ultra baja latencia de menos de 1 segundo
• En este commit se reorganizaron el nombre y la estructura del muxer WHIP, y se mejoraron los mensajes de error y logs de SSL/DTLS/RTC
• Se actualizaron parámetros clave del protocolo como curvas/perfiles DTLS, payload RTP e ICE STUN para alinearlos con las definiciones de Chrome, y los magic numbers se extrajeron a macros y funciones
• El handshake DTLS y el procesamiento de ICE se unificaron y optimizaron en una sola función, mejorando notablemente el rendimiento y la estabilidad
• Se corrigieron errores de transcodificación de audio y video (h264_mp4toannexb, timestamp de OPUS, configuración de marcadores, etc.), aumentando la compatibilidad con entornos WebRTC estándar
• Se aclaró la dependencia de OpenSSL, de modo que WHIP solo se compila cuando hay soporte para DTLS
• Con solo FFmpeg, ahora es más fácil construir entornos de broadcasting y streams en tiempo real basados en WebRTC, aprovechando características de ultra baja latencia frente a protocolos legacy como RTMP

---

avformat/whip: se añade soporte para el muxer WHIP en FFmpeg

Resumen de los cambios principales

• Introducción oficial del muxer basado en WHIP Version 3, con reorganización de la nomenclatura y la estructura interna
• El contexto de logs y los mensajes de error de SSL, DTLS y RTC ahora son mucho más claros
• Los magic numbers hardcodeados se extrajeron a macros y funciones separadas para mejorar la mantenibilidad
• Se ajustaron elementos como la lista de curvas DTLS y los nombres de perfiles SRTP para alinearlos con los estándares de FFmpeg y OpenSSL
• El magic number de ICE STUN y los tipos de payload RTP se actualizaron para coincidir con el estándar del navegador Chrome
• Se resolvieron problemas de procesamiento multimedia como tamaño de frame de audio, conversión H.264 MP4→AnnexB y timestamps de OPUS
• La lógica del handshake DTLS y del procesamiento ICE se integró en una única función, facilitando su mantenimiento
• Se aclararon las condiciones de soporte DTLS basadas en OpenSSL, mejorando los errores de compilación y la compatibilidad
• Se unificó la estructura interna de TLS/DTLS en áreas como SRTP, callbacks BIO e inicialización de claves/certificados CA
• Se modificaron y agregaron 13 archivos en total, incluyendo la creación de whip.c

Contexto y relevancia

• WHIP es un protocolo estándar basado en HTTP para la ingestión de streams sobre WebRTC, y es esencial para transmisiones en vivo de ultra baja latencia
• Hasta ahora, en FFmpeg la codificación y emisión por WebRTC requerían herramientas separadas o un relay complejo, pero con este merge ahora es posible emitir por WHIP con un solo comando de FFmpeg
• Esto marca un punto de inflexión técnico para conectar directamente con el ecosistema moderno de WebRTC en áreas como transmisiones en tiempo real, live commerce y videoconferencias

[GN⁺]

Opiniones de Hacker News

• Estoy súper entusiasmado con la transmisión por WebRTC; en el README de Broadcast Box y en el PR de OBS (enlace) explican bien por qué. Ahora que GStreamer, OBS y FFmpeg ya soportan WHIP, por fin llegamos a un protocolo de transmisión de video de propósito general que puede aplicarse en todas las plataformas. Después de años trabajando en transmisión open source + WebRTC, siento que esto es un hito enorme.
  • Antes jugaba dosbox remoto desde el teléfono vía VNC, pero ahora me dieron ganas de crear yo mismo una webapp con input handler y perder una cantidad infinita de tiempo con esta tecnología combinada con OBS.
  • Pregunta si hay planes de agregar multipath/failover-bonding en unidades móviles de streaming conectando varios módems 5G, por ejemplo modificando SRT para enviar H.265 por múltiples enlaces.
  • Sorprende ver broadcast-box y las contribuciones de desarrollo después de haber usado esto directamente en tantas plataformas distintas, como software de transmisión popular, móvil, web y embebido.
  • Expresa alegría al ver que su librería de webrtc ha sido útil en varios proyectos y ha influido en un espectro técnico tan amplio.
• Anuncian una implementación de WebRTC-HTTP Ingestion Protocol (WHIP): no se trata de manejar SCTP directamente, sino de un documento IETF de WHIP IDF que actúa como gateway vía HTTP con pares que usan WebRTC (ver enlace). Espera que algún día se pase de SCTP a un protocolo p2p basado en QUIC o WebTransport. También comenta interés en Media-over-Quic (MoQ), pero que el soporte en navegadores y su avance llevan años bastante lentos; comparte los enlaces relacionados quic.video y MoQ IETF introduction.
  • Preguntan de qué manera querría usar o exponer la parte de SCTP; como no hay mención ni propuesta al respecto en el borrador IETF de WHIP, queda ambiguo. La mayoría de los “WHIP Provider” soportan DataChannel, pero eso no está estandarizado.
• Preguntan si con la conexión directa entre FFmpeg y un sitio web ahora se pueden recibir de inmediato flujos de audio/video; se puede ver más detalle en la página de Phoronix (enlace).
  • Resumen: los programas que usan las librerías de FFmpeg, especialmente libavformat, podrían recibir y aprovechar directamente streams de WebRTC.
• Hay expectativa de que este cambio hará mucho más fácil montar streams self-hosted o un CDN de streaming propio, destacando la independencia y el rendimiento plug-and-play de ffmpeg.
  • En combinación con Simulcast, se espera una reducción drástica en costos y barreras de entrada; de hecho, broadcast-box nació también para bajar la barrera de entrada de self-hosting + WebRTC.
  • Comentan que usando LLM incluso se pueden sacar comandos one-liner para todo tipo de tareas de video con ffmpeg, elogiando muchísimo la experiencia con IA.
  • Siempre les viene a la mente la historieta xkcd 2347, que muestra de un vistazo lo versátil que es ffmpeg.
• Resulta llamativa la experiencia de encontrarse inesperadamente con gráficos de Anubis en ffmpeg, gnu y otros lugares.
• Les preocupa que agregar WHIP vuelva más riesgoso mantener ffmpeg en el sistema, ya que sienten que las vulnerabilidades de seguridad en WebRTC realmente causan muchas intrusiones, y recuerdan que en el pasado siempre lo desactivaban después de instalar el navegador.
  • Preguntan a qué vulnerabilidades de seguridad se refieren; mencionan que esta implementación es muy pequeña y expresan una fuerte confianza en que ofrece el mejor resultado posible para los usuarios.
  • Preguntan si se podrá elegir una opción como --without-whip para excluirlo por completo del build si no se quiere; opinan que eso sería lo ideal.
  • Como ffmpeg ha tenido bastantes problemas de seguridad en el pasado, lo mejor al procesar entrada de usuarios sigue siendo usar un entorno aislado; por ejemplo, levantar para cada tarea una imagen de Docker nueva que solo incluya ffmpeg y sus dependencias, o si hace falta procesar miniaturas o documentos, agregar también ClamAV, OpenOffice, ImageMagick, etc. Además, recomiendan operar los servidores que manejan archivos generados por usuarios en una VLAN lo más aislada posible o, en AWS, solo dentro de un security group. Aclaran que no es una crítica a cada proyecto en particular, sino un énfasis en lo difícil que son los formatos binarios y en la importancia de las medidas preventivas de seguridad; también sugieren revisar el caso de 4chan. La página de seguridad de ffmpeg está aquí.
• Preguntan cómo va la actividad de auditoría de seguridad de ffmpeg, comentando que en el sitio oficial da una impresión algo reactiva.
• Preguntan si ahora será posible grabar con ffmpeg el stream de audio de videoconferencias en Jitsi.
• Preguntan si alguien logró aplicar con éxito el soporte de WHIP al compilar FFmpeg desde el código fuente, diciendo que fue difícil encontrar las opciones correctas de ./configure.
  • Indican que las opciones necesarias son --enable-muxer=whip y --enable-openssl.
• Están contando los días para que esta función llegue a Jellyfin.
  • En respuesta, preguntan qué beneficio funcional le aportaría esto a Jellyfin.