FFmpeg fusionne la prise en charge du streaming ultra-faible latence WebRTC (WHIP)

• FFmpeg intègre officiellement un muxer WHIP (WebRTC-HTTP Ingestion Protocol), avec prise en charge directe du streaming ultra-faible latence à moins d’une seconde
• Ce commit revoit le nommage et la structure du muxer WHIP, et améliore les messages d’erreur et les logs SSL/DTLS/RTC
• Des paramètres de protocole clés comme les courbes/profils DTLS, la charge utile RTP, ICE STUN, etc. sont mis à jour pour correspondre aux définitions de Chrome, et les magic numbers sont extraits en macros et fonctions
• Le handshake DTLS et le traitement ICE sont unifiés et optimisés dans une seule fonction, avec une nette amélioration des performances et de la stabilité
• Des bugs de transcodage audio et vidéo (h264_mp4toannexb, timestamp OPUS, réglage des marqueurs, etc.) sont corrigés, améliorant la compatibilité avec les environnements WebRTC standard
• La dépendance à OpenSSL est clarifiée, afin que WHIP ne soit compilé qu’en présence du support DTLS
• Avec FFmpeg seul, il devient plus simple de mettre en place des environnements de diffusion et de flux en temps réel basés sur WebRTC, en tirant parti de la très faible latence par rapport aux protocoles legacy comme RTMP

---

avformat/whip : ajout de la prise en charge du muxer WHIP dans FFmpeg

Résumé des principaux changements

• Introduction officielle d’un muxer basé sur WHIP Version 3, avec réorganisation du nommage et de la structure interne
• Les contextes de logs et messages d’erreur de SSL, DTLS et RTC deviennent nettement plus clairs
• Les magic numbers codés en dur sont extraits en macros et fonctions dédiées pour renforcer la maintenabilité
• La liste des courbes DTLS, les noms de profils SRTP et d’autres éléments sont corrigés pour s’aligner sur les standards de FFmpeg et OpenSSL
• Les magic numbers ICE STUN et les types de charge utile RTP sont mis à jour pour correspondre au standard du navigateur Chrome
• Résolution de problèmes de traitement média liés à la taille des trames audio, à la conversion H.264 MP4→AnnexB et aux timestamps OPUS
• La logique du handshake DTLS et du traitement ICE est unifiée dans une seule fonction, facilitant la maintenance
• Les conditions de prise en charge de DTLS via OpenSSL sont clarifiées, avec des améliorations sur les erreurs de build et la compatibilité
• Intégration des structures internes TLS/DTLS autour de SRTP, des callbacks BIO et de l’initialisation des clés/certificats CA
• 13 fichiers au total sont modifiés ou ajoutés, dont la création de whip.c

Contexte et portée

• WHIP est un protocole standard HTTP destiné à l’ingestion de flux basés sur WebRTC, indispensable pour la diffusion live à très faible latence
• Jusqu’ici, l’encodage et l’émission WebRTC avec FFmpeg nécessitaient des outils séparés ou une chaîne de relais complexe ; avec cette fusion, une commande FFmpeg unique suffit pour émettre via WHIP
• Cela marque un tournant technique permettant une interopérabilité directe avec l’écosystème WebRTC moderne dans des domaines variés comme le streaming en direct, le live commerce et la visioconférence

[GN⁺]

Avis sur Hacker News

• Je suis vraiment emballé par le broadcast via WebRTC ; j’explique pourquoi dans le README de Broadcast Box et le PR OBS ici. Maintenant que GStreamer, OBS et FFmpeg prennent tous en charge WHIP, on atteint enfin un protocole universel de diffusion vidéo applicable sur toutes les plateformes. Avec plusieurs années de travail sur le broadcast open source + WebRTC, je considère cette avancée comme une étape majeure.
  • J’avais l’habitude de jouer à des jeux dosbox distants sur mon téléphone via VNC ; maintenant j’ai envie de créer moi-même une webapp de gestion des entrées et de me lancer dans un nouveau défi chronophage avec cette techno + OBS.
  • Question : est-il prévu d’ajouter sur une unité de streaming mobile une fonctionnalité de multipath/failover-bonding en connectant plusieurs modems 5G (par exemple via une version modifiée de SRT pour transmettre du H.265 sur plusieurs liens) ?
  • Impressionné après avoir vu une utilisation directe sur des plateformes variées comme des logiciels de diffusion populaires, le mobile, le web et l’embarqué, ainsi que par broadcast-box et les contributions de développement.
  • Heureux de voir ma bibliothèque webrtc utilisée utilement dans plusieurs projets et avoir un impact sur un large spectre technique.
• Annonce d’une implémentation de WebRTC-HTTP Ingestion Protocol (WHIP) — il ne s’agit pas de manipuler SCTP lui-même, mais d’un document IETF WHIP IDF servant de passerelle via HTTP avec des pairs utilisant WebRTC ; voir le document (lien). J’espère qu’un jour on passera de SCTP à un protocole p2p basé sur QUIC ou WebTransport. Je m’intéresse à Media-over-Quic (MoQ), mais le support navigateur et les progrès semblent ralentis depuis des années ; liens associés : quic.video et MoQ IETF introduction
  • Question sur la manière dont on voudrait exploiter/exposer la partie SCTP ; c’est flou car le brouillon IETF de WHIP n’en parle pas vraiment et ne propose rien. La plupart des « WHIP Provider » prennent en charge DataChannel, mais ce n’est pas standardisé.
• Question : est-ce qu’une connexion directe entre FFmpeg et un site web permettrait de recevoir immédiatement des flux audio/vidéo ? Plus de détails sur la page Phoronix (lien).
  • Résumé : les programmes utilisant les bibliothèques FFmpeg (en particulier libavformat) peuvent directement recevoir et exploiter des flux WebRTC.
• On s’attend à ce que ce changement facilite énormément la mise en place de flux auto-hébergés / d’un CDN de streaming auto-hébergé, en soulignant l’indépendance et le côté plug-and-play de ffmpeg.
  • Combiné à Simulcast, cela pourrait réduire radicalement les coûts et les barrières à l’entrée ; broadcast-box a d’ailleurs été créé pour abaisser la barrière d’entrée du self-hosting + WebRTC.
  • Grâce aux LLM, on peut même obtenir des commandes one-liner pour toutes sortes de travaux vidéo liés à ffmpeg ; avis extrêmement positif sur l’usage de l’IA.
  • Le dessin xkcd 2347 me revient toujours en tête, tant il montre bien la polyvalence de ffmpeg.
• L’expérience de tomber de façon inattendue sur les graphismes Anubis dans ffmpeg, gnu et ailleurs a marqué les esprits.
• Inquiétude : l’ajout de WHIP ne rend-il pas plus risqué le fait de garder ffmpeg sur son système ? Impression que les vulnérabilités WebRTC sont réellement à l’origine de nombreuses compromissions, et souvenir d’avoir toujours désactivé cela après l’installation des navigateurs.
  • Question : de quelles vulnérabilités de sécurité parle-t-on ? Mention que cette implémentation est très petite, avec une forte conviction d’offrir le meilleur résultat possible aux utilisateurs.
  • Question : peut-on avoir une option du type --without-whip pour l’exclure complètement du build si on n’en veut pas ? Ce serait l’idéal.
  • FFmpeg a déjà eu pas mal de problèmes de sécurité par le passé ; pour traiter des entrées utilisateur, le mieux reste toujours un environnement isolé. Par exemple, utiliser à chaque tâche une nouvelle image Docker ne contenant que ffmpeg et ses dépendances ; ou, si l’on doit aussi gérer des miniatures ou des documents, recommander d’ajouter ClamAV, OpenOffice, ImageMagick, etc. Il est aussi conseillé d’isoler autant que possible les serveurs qui manipulent des fichiers générés par les utilisateurs, par exemple sur un VLAN séparé ou, sur AWS, uniquement à l’intérieur d’un security group. Ce n’est pas une critique d’un projet particulier, mais un rappel de la difficulté intrinsèque des formats binaires et de l’importance des mesures de sécurité préventives ; voir aussi le cas de 4chan. La page sécurité de ffmpeg est ici
• Question sur l’état des audits de sécurité de ffmpeg ; impression partagée qu’ils semblent un peu réactifs sur le site officiel.
• Question : peut-on désormais enregistrer le flux audio d’une visioconférence Jitsi avec ffmpeg ?
• Quelqu’un a-t-il réussi à activer le support de WHIP dans une build depuis les sources de FFmpeg ? Difficulté à trouver les bonnes options ./configure.
  • Réponse : les options nécessaires sont --enable-muxer=whip et --enable-openssl.
• J’attends avec impatience le jour où cette fonctionnalité arrivera dans Jellyfin.
  • En réponse, question sur l’aide fonctionnelle concrète que cela apporterait à Jellyfin.