FFmpeg integriert Unterstützung für ultraniedrig-latentes Streaming mit WebRTC (WHIP)

 (git.ffmpeg.org)
3 Punkte von GN⁺ 2025-06-05 | 1 Kommentare | Auf WhatsApp teilen
  • In FFmpeg avformat/whip wurde ein WHIP-Muxer aufgenommen, sodass sich WebRTC-basiertes Streaming mit unter 1 Sekunde Latenz direkt in FFmpeg handhaben lässt
  • Die Änderungen basieren auf WHIP Version 3; neben dem Namen des Muxers und der Implementierung wurden auch SSL-, DTLS- und RTC-Log-Kontexte sowie Fehlermeldungen bereinigt
  • Interne Magic Numbers der Implementierung wurden durch Makros und Funktionen ersetzt; auch die Verarbeitung der DTLS Curve List, des SRTP-Profils, der ICE-STUN-Magic-Number und des RTP-Payload-Typs wurde überarbeitet
  • Im Medienpfad wird statt einer festen Frame-Größe rtc->audio_par->frame_size verwendet, und für die Annex-B-Konvertierung bei MP4/ISOM-Eingaben kommt h264_mp4toannexb zum Einsatz
  • Die Build-Konfiguration wurde so geändert, dass whip nur bei aktiviertem DTLS eingeschaltet wird; aktuell ist die Unterstützung auf OpenSSL beschränkt

Hinzufügen des WHIP-Muxers und Anbindung an den Build

Bereinigung der Verarbeitung von DTLS, ICE und RTP

  • Der WHIP-Muxer wurde zusammen mit der Umbenennung der Implementierung überarbeitet; **SSL-, DTLS- und RTC-**Fehlermeldungen sowie Log-Kontexte wurden verbessert
  • Magic Numbers wurden durch Makros ersetzt, und Teile der Logik wurden in Funktionen ausgelagert
    • Auch die Log-Level wurden klarer abgestimmt
  • Im DTLS-Pfad gab es mehrere Änderungen in Bezug auf Kompatibilität und Performance
    • Die DTLS Curve List wurde aktualisiert
    • Die SRTP-Profilnamen für FFmpeg und OpenSSL wurden überarbeitet
    • DTLS-Handshake und ICE-Verarbeitung wurden zur Performance-Verbesserung optimiert
    • Durch ein einzelnes Handshake-Timeout und die Server-Rolle wird ARQ vermieden
  • Die ICE-Verarbeitung wurde in Richtung einer Zusammenführung von Request/Response und DTLS-Handshake in einer einzelnen Funktion bereinigt
    • Die ICE-STUN-Magic-Number wurde angepasst
  • Der RTP-Payload-Typ wurde auf Basis der Chrome-Definitionen aktualisiert

Medienverarbeitung und OpenSSL-Einschränkung

  • Auf der Audio-Seite wurde die feste Frame-Größe durch die Verwendung von rtc->audio_par->frame_size ersetzt
  • Für die Konvertierung von MP4/ISOM-Eingaben nach Annex B wird h264_mp4toannexb verwendet
  • Das OPUS-Timestamp-Problem und das Setzen des Markers nach Einsatz des BSF wurden ebenfalls korrigiert
  • TLS- und DTLS-Implementierung wurden in einer gemeinsamen Struktur zusammengeführt
    • BIO-Callback, Read, Write, print_ssl_error, openssl_init_ca_key_cert und init_bio_method werden gemeinsam genutzt
    • Es wird dieselbe Datenstruktur verwendet
  • Ein OpenSSL-Build-Fehler wurde behoben, damit es mit Pion funktioniert
  • configure wurde so geändert, dass whip nur bei aktiviertem dtls eingeschaltet wird
    • Derzeit wird nur OpenSSL unterstützt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-05
Meinungen auf Hacker News

  • Auf WebRTC-Broadcasting freue ich mich wirklich. Die Gründe habe ich im Broadcast-Box-README und im OBS-PR zusammengefasst.
    Da jetzt GStreamer, OBS und FFmpeg alle WHIP unterstützen, gibt es damit gewissermaßen ein universelles Video-Broadcast-Protokoll, das sich auf allen Plattformen nutzen lässt – Mobile, Web, Embedded, Broadcast-Software usw.
    Ich arbeite seit Jahren an Open Source und WebRTC-Broadcasting, und ich sehe das als großen Meilenstein.
    [0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
    [1] https://github.com/obsproject/obs-studio/pull/7926

    • Aus Sicht von jemandem, der im Bereich Event-Broadcasting arbeitet, könnte diese Änderung OBS zu einer realistischen Alternative zu professioneller Software wie vMix machen. Besonders die P2P-Unterstützung und die Möglichkeit, mehrere Szenen zu übertragen, wirken sehr wertvoll.
    • Ich frage mich, ob es Videoplayer gibt, die WebRTC-Streams abspielen können. Als ich das zuletzt geprüft habe, unterstützten VLC und andere populäre Tools das noch nicht.

  • Es geht nicht um den SCTP-Teil. Tatsächlich wurde das WebRTC-HTTP Ingestion Protocol, kurz WHIP, implementiert – ein HTTP-Protokoll mit niedriger Latenz, um sich mit einem Gateway zu verbinden, das über das SCTP-basierte WebRTC-Protokoll mit Peers kommuniziert.
    https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
    Ich hoffe, dass wir irgendwann statt SCTP auf ein P2P-Protokoll auf Basis von QUIC oder WebTransport wechseln können. QUIC erledigt auf bestehendem UDP vieles von dem, was SCTP getan hat, gut und erhöht Komplexität und Implementierungsunterschiede nicht stark.
    Einer der Kandidaten ist Media-over-QUIC (MoQ), aber in Browsern gibt es kein P2P-QUIC, und die Entwicklung in diese Richtung scheint seit einigen Jahren zu stagnieren.
    https://quic.video/ https://datatracker.ietf.org/group/moq/about/

    • Ich frage mich, wie man den SCTP-Teil sinnvoll offenlegen und nutzen könnte. Im WHIP-IETF-Entwurf scheint es dazu keine Erwähnung oder Empfehlung zu geben.
      Die meisten WHIP-Anbieter unterstützen zwar auch DataChannel, standardisiert ist das aber noch nicht.

  • Ich frage mich, was das bedeutet. Heißt das, dass eine Website sich direkt mit einer FFmpeg-Instanz verbinden und einen Audio- oder Videostream empfangen kann?
    Die Erklärung bei Phoronix ist etwas ausführlicher: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

    • Es scheint zu bedeuten, dass Programme, die FFmpeg-Bibliotheken verwenden, insbesondere libavformat, WebRTC-Streams empfangen können.

  • Damit dürfte es viel einfacher werden, selbst gehostete Streams oder ein Streaming-CDN aufzubauen.
    FFmpeg ist wirklich erstaunliche eigenständige Plug-and-play-Mediensoftware, wenn man nur weiß, wie man sie benutzt.

    • Darauf freue ich mich sehr. Besonders mit Simulcast könnte man das für Leute sehr günstig und einfach machen.
      Ich habe https://github.com/Glimesh/broadcast-box gebaut, weil ich Self-Hosting und WebRTC deutlich einfacher machen wollte.
    • LLMs kennen sich wirklich gut mit der Nutzung von FFmpeg aus. Bei fast jeder videobezogenen Aufgabe kann man fragen, und sie erzeugen einem den passenden einzeiligen ffmpeg-Befehl.
    • Absolut, und dieser Comic kommt mir dabei immer in den Sinn: https://xkcd.com/2347/

  • Der XMPP-Client Gajim hat lange darauf gewartet. Die Audio-/Videoanruffunktion lag praktisch brach, und man hat geduldig darauf gewartet, dass FFmpeg es hoffentlich wieder einfacher macht, sie hinzuzufügen.

    • Ich frage mich, ob Gajim und XMPP überhaupt noch genutzt werden. Ich vermisse die Zeiten, in denen man Chat-Apps wie früher mit pidgin genutzt hat.
      Inzwischen ist alles ein geschlossener Garten oder ein app-spezifischer Dienst.

  • Es ist schön, unerwartet die Anubis-Grafik zu sehen. Bisher habe ich sie unter anderem bei ffmpeg und gnu gesehen.

    • Mir gefällt sie auch, aber diesmal lässt sie mich nicht hinein.

  • Ich hoffe, dass es dadurch nicht riskanter wird, ffmpeg auf dem System zu haben. WebRTC-Sicherheitslücken sind die Ursache vieler Kompromittierungen, und es ist eine der ersten Funktionen, die ich nach der Installation eines Browsers deaktiviere.

    • Ich frage mich, welche Sicherheitslücken gemeint sind.
      Diese Implementierung ist sehr klein, und ich bin zu 100 % überzeugt, dass sie den Nutzern das Bestmögliche bietet.
    • ffmpeg ist High-Performance-Code in C, der mit obskuren Codecs und Binärformaten umgeht; da muss man sich nicht unbedingt nur wegen WebRTC Sorgen machen.
    • Ich frage mich, ob man es mit einem Argument wie --without-whip aus dem Build herausnehmen kann, wenn man es nicht will oder braucht. Das wäre wohl ideal.
    • ffmpeg hatte auch in der Vergangenheit viele Sicherheitsprobleme [1], daher ist es ohnehin Best Practice, es beim Umgang mit Nutzereingaben gut zu isolieren.
      Sinnvoll wäre ein Docker-Image, das nur ffmpeg und seine Abhängigkeiten enthält, und für jede Konvertierungsaufgabe docker run auszuführen. Wenn auch Bild- oder Dokument-Thumbnails erzeugt werden müssen, kann man ClamAV, OpenOffice und ImageMagick ebenfalls hineinpacken.
      Persönlich finde ich, dass Server, die nutzergenerierte Dateien nicht nur entgegennehmen und ausliefern, sondern weiterverarbeiten, in ein separates, stark abgesichertes VLAN gehören – oder bei AWS in eine Security Group.
      Das ist keine uninformierte Kritik an den genannten Projekten. Sicherheit ist schwer, besonders wenn man mit über lange Zeit gewachsenen und manchmal auf fragwürdige Weise per Reverse Engineering erschlossenen Binärformaten umgeht. Es ist klug, das anzuerkennen, bevor man wie 4chan erwischt wird.
      [1] https://ffmpeg.org/security.html

  • Wirklich gut. Ich baue gerade eine webbasierte Fernsteuerung, und wenn ich damit ffmpeg gdigrab in einen WebRTC-Stream verwandeln kann, den Clients direkt konsumieren können – ohne meinen aktuellen ExpressJS-Workaround –, wäre ich sehr zufrieden.

  • Interessant, dass ich in iOS Safari immer wieder an der Bot-Erkennung hängen bleibe. Das passiert sowohl im Firmen-WLAN als auch über Mobilfunkdaten.
    Ich wünschte, Anubis ließe mich mal durch.

    • Ich frage mich, ob eine "access denied"-Seite erscheint oder ob die Challenge endlos wiederholt wird.
    • Ich frage mich, ob du vielleicht ein Dual-Stack-Netzwerk nutzt.

  • Anubis lässt mich nicht durch ;(