FFmpeg fusionne la prise en charge du streaming WebRTC (WHIP) à très faible latence

 (git.ffmpeg.org)
3 points par GN⁺ 2025-06-05 | 1 commentaires | Partager sur WhatsApp
  • Un muxer WHIP a été ajouté à avformat/whip dans FFmpeg, permettant de gérer dans FFmpeg le streaming WebRTC avec une latence inférieure à une seconde
  • Le changement se base sur WHIP Version 3, et clarifie non seulement le nom et l’implémentation du muxer, mais aussi les contextes de logs SSL·DTLS·RTC et les messages d’erreur
  • Les nombres magiques internes à l’implémentation ont été remplacés par des macros et fonctions, et le traitement de la liste de courbes DTLS, des profils SRTP, des nombres magiques ICE STUN et des types de payload RTP a également été affiné
  • Dans le chemin média, rtc->audio_par->frame_size est utilisé à la place d’une taille de trame fixe, et h264_mp4toannexb est utilisé pour la conversion Annex B des entrées MP4/ISOM
  • La configuration de build a été modifiée afin que whip ne soit activé que lorsque DTLS est activé ; la cible actuellement prise en charge se limite à OpenSSL

Ajout du muxer WHIP et intégration au build

Clarification du traitement DTLS·ICE·RTP

  • Le muxer WHIP a été renommé et son implémentation affinée, avec une amélioration des messages d’erreur et des contextes de logs SSL·DTLS·RTC
  • Les nombres magiques ont été remplacés par des macros, et une partie de la logique a été séparée en fonctions
    • Les niveaux de logs ont aussi été ajustés pour être plus explicites
  • Plusieurs changements liés à la compatibilité et aux performances ont été apportés au chemin DTLS
    • La liste de courbes DTLS a été mise à jour
    • Les noms des profils SRTP pour FFmpeg et OpenSSL ont été affinés
    • Le handshake DTLS et le traitement ICE ont été optimisés pour améliorer les performances
    • Un timeout de handshake unique et le rôle serveur sont utilisés afin d’éviter l’ARQ
  • Le traitement ICE a été réorganisé de façon à regrouper les requêtes/réponses et le handshake DTLS dans une seule fonction
    • Les nombres magiques ICE STUN ont été affinés
  • Les types de payload RTP ont été mis à jour sur la base de la définition de Chrome

Traitement média et contrainte OpenSSL

  • Côté audio, la taille de trame fixe a été remplacée par l’utilisation de rtc->audio_par->frame_size
  • h264_mp4toannexb est utilisé pour convertir les entrées MP4/ISOM en Annex B
  • Le problème de timestamp OPUS et le réglage du marqueur après utilisation de BSF ont aussi été corrigés
  • Les implémentations TLS et DTLS ont été réunies dans une structure commune
    • BIO callback, read, write, print_ssl_error, openssl_init_ca_key_cert et init_bio_method sont partagés
    • La même structure de données est utilisée
  • Une erreur de build OpenSSL a été corrigée afin de fonctionner avec Pion
  • configure a été modifié pour n’activer whip que lorsque dtls est activé
    • La cible actuellement prise en charge est OpenSSL

À lire aussi

1 commentaires

 
GN⁺ 2025-06-05
Avis de Hacker News

  • La diffusion WebRTC me réjouit vraiment. J’ai résumé les raisons dans le README de Broadcast Box et dans la PR d’OBS
    Maintenant que GStreamer, OBS et FFmpeg prennent tous en charge WHIP, on a en quelque sorte un protocole universel de diffusion vidéo utilisable sur toutes les plateformes : mobile, web, embarqué, logiciels de diffusion, etc.
    Je travaille depuis des années sur l’open source et la diffusion WebRTC, et je vois ça comme un jalon majeur
    [0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
    [1] https://github.com/obsproject/obs-studio/pull/7926

    • En tant que personne qui travaille dans la diffusion d’événements, ce changement pourrait faire d’OBS une alternative réaliste à des logiciels professionnels comme vMix. En particulier, la prise en charge du P2P et la possibilité de diffuser plusieurs scènes semblent très précieuses
    • Je me demande s’il existe un lecteur vidéo capable de lire un flux WebRTC. La dernière fois que j’ai vérifié, VLC et les autres outils populaires ne le prenaient pas encore en charge

  • Ce n’est pas la partie SCTP. En réalité, il s’agit de l’implémentation de WebRTC-HTTP Ingestion Protocol, ou WHIP, un protocole HTTP à faible latence permettant de se connecter à une passerelle qui communique avec les pairs via le protocole WebRTC basé sur SCTP
    https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
    J’aimerais qu’un jour on puisse passer à un protocole P2P basé sur QUIC ou WebTransport plutôt que SCTP. QUIC gère bien, au-dessus de l’UDP existant, ce que SCTP faisait, sans augmenter fortement la complexité ni les écarts d’implémentation
    L’un des candidats est Media-over-QUIC (MoQ), mais les navigateurs n’ont pas de QUIC P2P, et les progrès de ce côté semblent au point mort depuis des années
    https://quic.video/ https://datatracker.ietf.org/group/moq/about/

    • Je me demande comment il faudrait exposer et utiliser la partie SCTP. Le brouillon IETF de WHIP ne semble contenir aucune mention ni proposition à ce sujet
      La plupart des fournisseurs WHIP prennent aussi en charge DataChannel, mais ce n’est pas encore standardisé

  • Je me demande ce que ça signifie. Est-ce que cela veut dire qu’un site web peut se connecter directement à une instance FFmpeg pour recevoir un flux audio ou vidéo ?
    L’explication de Phoronix est un peu plus détaillée : https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

    • On dirait que cela signifie que les programmes utilisant les bibliothèques FFmpeg, en particulier libavformat, pourront recevoir des flux WebRTC

  • Ça devrait rendre beaucoup plus simple la création de flux auto-hébergés ou de CDN de streaming
    FFmpeg est un logiciel média autonome et plug-and-play vraiment impressionnant quand on sait s’en servir

    • Je suis vraiment impatient. Surtout avec Simulcast, on pourrait permettre aux gens de créer cela de façon très bon marché et simple
      J’ai créé https://github.com/Glimesh/broadcast-box parce que je voulais rendre l’auto-hébergement et WebRTC beaucoup plus faciles
    • Les LLM connaissent vraiment bien l’utilisation de FFmpeg. Pour presque n’importe quelle tâche liée à la vidéo, il suffit de leur demander et ils génèrent une commande ffmpeg en une ligne adaptée
    • Tout à fait, et cette BD me revient toujours en tête : https://xkcd.com/2347/

  • Le client XMPP Gajim attendait ça depuis longtemps. Les fonctionnalités d’appels audio/vidéo étaient pratiquement à l’abandon, et le projet attendait patiemment que FFmpeg permette de les réintégrer plus facilement

    • Je me demande si Gajim et XMPP sont encore utilisés. L’époque où l’on utilisait des applis de chat via pidgin me manque
      Maintenant, tout est devenu des jardins fermés ou des services propres à chaque application

  • Ça fait plaisir de tomber de façon inattendue sur le graphisme d’Anubis. Jusqu’ici, je l’ai vu notamment sur ffmpeg et gnu

    • Moi aussi je l’aime bien, mais cette fois il ne me laisse pas entrer

  • J’espère que cela ne rendra pas la présence de ffmpeg sur un système plus dangereuse. Les failles de sécurité WebRTC sont à l’origine de nombreuses compromissions, et c’est l’une des premières fonctionnalités que je désactive quand j’installe un navigateur

    • Je me demande de quelles failles de sécurité il est question
      Cette implémentation est très petite, et je suis convaincu à 100 % qu’elle offre aux utilisateurs le mieux possible
    • ffmpeg est déjà du code haute performance en C qui manipule des codecs obscurs et des formats binaires, donc il ne semble pas nécessaire de s’inquiéter uniquement de WebRTC
    • Je me demande si, lorsqu’on n’en veut pas ou qu’on n’en a pas besoin, on peut l’exclure de la compilation avec un argument du type --without-whip. Ce serait idéal
    • ffmpeg a déjà eu beaucoup de problèmes de sécurité par le passé [1], donc lorsqu’il traite des entrées utilisateur, la bonne pratique reste de toute façon de bien l’isoler
      Une bonne approche consiste à créer une image Docker ne contenant que ffmpeg et ses dépendances, puis à lancer docker run pour chaque tâche de conversion. Si l’on doit aussi générer des vignettes d’images ou de documents, on peut y ajouter ClamAV, OpenOffice et ImageMagick
      Personnellement, je pense qu’un serveur qui va au-delà de la simple réception et distribution de fichiers générés par les utilisateurs, et qui les traite, devrait être placé dans un VLAN séparé et fortement verrouillé, ou dans un Security Group sur AWS
      Ce n’est pas une critique ignorante des projets mentionnés. La sécurité est difficile, surtout lorsqu’on manipule des formats binaires accumulés au fil du temps et parfois rétroconçus de façon douteuse. Il est plus sage de le reconnaître avant de subir le sort de 4chan
      [1] https://ffmpeg.org/security.html

  • C’est vraiment bien. Je construis un système de contrôle à distance basé sur le web, et si cela permet de transformer ffmpeg gdigrab en flux WebRTC que le client peut consommer directement, sans le contournement ExpressJS que j’utilise actuellement, j’en serais très satisfait

  • C’est intéressant de voir que je reste bloqué par la détection de bots sur iOS Safari. Ça arrive aussi bien sur le Wi-Fi de l’entreprise que sur les données cellulaires
    J’aimerais bien qu’Anubis me laisse passer

    • Je me demande si c’est une page "access denied" qui s’affiche, ou si le challenge tourne en boucle indéfiniment
    • Je me demande si vous utilisez un réseau dual-stack

  • Anubis ne me laisse pas passer ;(