FFmpeg integriert Unterstützung für ultraniedrige Latenz beim Streaming mit WebRTC (WHIP)

• Für FFmpeg wurde offiziell ein WHIP(WebRTC-HTTP Ingestion Protocol)-Muxer hinzugefügt, der ultraniedriges Streaming mit weniger als 1 Sekunde Latenz direkt unterstützt
• In diesem Commit wurden Benennung und Struktur des WHIP-Muxers überarbeitet, außerdem wurden SSL-/DTLS-/RTC-Fehlermeldungen und Logs verbessert
• Wichtige Protokollparameter wie DTLS-Kurven/Profile, RTP-Payloads, ICE STUN usw. wurden an die Chrome-Definitionen angepasst, und Magic Numbers wurden in Makros und Funktionen ausgelagert
• DTLS-Handshake und ICE-Verarbeitung wurden in einer Funktion zusammengeführt und optimiert, wodurch sich Leistung und Stabilität deutlich verbessern
• Fehler bei Audio- und Video-Transkodierung (h264_mp4toannexb, OPUS-Zeitstempel, Marker-Setzung usw.) wurden behoben, was die Kompatibilität mit standardmäßigen WebRTC-Umgebungen erhöht
• Die Abhängigkeit von OpenSSL wurde klarer definiert, sodass WHIP nur bei aktiviertem DTLS-Support gebaut wird
• Mit FFmpeg allein wird der Aufbau einer WebRTC-basierten Broadcast- und Echtzeit-Streaming-Umgebung einfacher, und die Eigenschaften ultraniedriger Latenz können gegenüber Legacy-Protokollen wie RTMP besser genutzt werden

---

avformat/whip: Unterstützung für den FFmpeg-WHIP-Muxer hinzugefügt

Zusammenfassung der wichtigsten Änderungen

• Offizielle Einführung eines Muxers auf Basis von WHIP Version 3, inklusive Überarbeitung interner Bezeichnungen und Strukturen
• Der Log-Kontext und die Fehlermeldungen für SSL, DTLS und RTC sind deutlich klarer geworden
• Hartkodierte Magic Numbers wurden in Makros und separate Funktionen ausgelagert, was die Wartbarkeit verbessert
• Listen für DTLS-Kurven, SRTP-Profilnamen und weitere Punkte wurden an die FFmpeg- und OpenSSL-Standards angepasst
• ICE-STUN-Magic-Number und RTP-Payload-Typen wurden so aktualisiert, dass sie mit dem Standard des Chrome-Browsers übereinstimmen
• Probleme bei der Medienverarbeitung wie Audio-Frame-Größe, H.264-MP4→AnnexB-Konvertierung und OPUS-Zeitstempel wurden behoben
• Die Logik für DTLS-Handshake und ICE-Verarbeitung wurde zur einfacheren Verwaltung in einer einzigen Funktion zusammengeführt
• Die Bedingungen für DTLS-Support auf OpenSSL-Basis wurden klarer definiert, wodurch sich Build-Fehler und Kompatibilität verbessern
• Interne TLS-/DTLS-Strukturen wie SRTP, BIO-Callbacks sowie die Initialisierung von CA-Schlüsseln/Zertifikaten wurden zusammengeführt
• Insgesamt 13 Dateien wurden geändert oder neu hinzugefügt, darunter die neue Datei whip.c

Hintergrund und Bedeutung

• WHIP ist ein HTTP-basiertes Standardprotokoll für die Stream-Einspeisung auf WebRTC-Basis und essenziell für Live-Streaming mit ultraniedriger Latenz
• Bisher waren für WebRTC-Encoding und -Übertragung mit FFmpeg separate Tools oder komplexe Relay-Konfigurationen nötig, doch mit diesem Merge ist nun WHIP-Streaming per einzelnem FFmpeg-Befehl möglich
• Das ist ein technischer Wendepunkt, um in Bereichen wie Echtzeit-Broadcasting, Live-Commerce und Videokonferenzen direkt mit dem modernen WebRTC-Ökosystem zu interagieren

[GN⁺]

Hacker-News-Kommentare

• Ich bin total begeistert von WebRTC-Broadcasting; im README von Broadcast Box und im OBS-PR-Link habe ich zusammengefasst, warum. Jetzt, da GStreamer, OBS und FFmpeg alle WHIP unterstützen, haben wir ein universelles Video-Broadcast-Protokoll erreicht, das sich plattformübergreifend einsetzen lässt. Nach jahrelanger Arbeit an Open Source + WebRTC-Broadcasting halte ich das für einen großen Meilenstein.
  • Ich habe früher Remote-DOSBox-Spiele per VNC auf dem Handy gespielt, und jetzt habe ich Lust auf eine neue Herausforderung, bei der ich direkt eine Input-Handler-Web-App baue und mit dieser Technik + OBS unendlich Zeit verschwende.
  • Frage, ob geplant ist, bei mobilen Streaming-Einheiten mehrere 5G-Modems anzubinden und Multipath-/Failover-Bonding-Funktionen hinzuzufügen (z. B. per SRT-Modifikation H.265 über mehrere Links zu senden).
  • Beeindruckt von broadcast-box und den Entwicklungsbeiträgen, nachdem ich die direkte Nutzung auf vielen Plattformen wie populärer Broadcast-Software, Mobilgeräten, Web und Embedded selbst erlebt habe.
  • Freude darüber, dass meine WebRTC-Bibliothek in mehreren Projekten nützlich eingesetzt wird und Einfluss auf ein breites technisches Spektrum hatte.
• Hinweis auf eine Implementierung des WebRTC-HTTP Ingestion Protocol (WHIP) — statt SCTP selbst zu behandeln, fungiert man über HTTP als Gateway für Peers, die WebRTC verwenden; siehe das WHIP-IETF-Dokument (Link). Ich hoffe, dass wir irgendwann statt SCTP zu einem p2p-Protokoll auf Basis von QUIC oder WebTransport übergehen. Ich interessiere mich für Media-over-Quic (MoQ), aber Browser-Support und Fortschritt wirken seit Jahren langsam. Relevante Links: quic.video und MoQ IETF introduction.
  • Frage, wie man den SCTP-Teil nutzen oder exponieren möchte; da es im WHIP-IETF-Entwurf keine relevante Erwähnung oder Vorschläge gibt, ist das unklar. Die meisten „WHIP Provider“ unterstützen zwar DataChannel, aber das ist nicht standardisiert.
• Frage, ob FFmpeg durch direkte Verbindung mit der Website sofort Audio-/Video-Streams empfangen kann; mehr Details gibt es auf der Phoronix-Seite (Link).
  • Zusammenfassende Erklärung, dass Programme, die FFmpeg-Bibliotheken (insbesondere libavformat) verwenden, WebRTC-Streams direkt empfangen und nutzen können.
• Erwartung, dass diese Änderung den Aufbau selbstgehosteter Streams bzw. eines Streaming-CDN deutlich erleichtern wird; betont werden FFmpegs Unabhängigkeit und Plug-and-Play-Fähigkeit.
  • In Kombination mit Simulcast dürften Kosten und Einstiegshürden drastisch sinken; broadcast-box wurde ebenfalls mit dem Ziel entwickelt, die Einstiegshürde für Self-Hosting + WebRTC zu senken.
  • Mit LLMs lassen sich für alle möglichen Videoaufgaben rund um ffmpeg sogar One-Liner-Kommandos erzeugen; große Begeisterung über die Nutzung von AI.
  • Dabei fällt mir immer der Comic xkcd 2347 ein, der die Vielseitigkeit von ffmpeg auf einen Blick zeigt.
• Eindrucksvoll war die Erfahrung, Anubis-Grafiken unerwartet bei ffmpeg und gnu usw. zu sehen.
• Sorge, ob das Beibehalten von ffmpeg im System durch die Ergänzung von WHIP nicht noch riskanter wird; WebRTC-Sicherheitslücken seien gefühlt oft Ursache realer Kompromittierungen, und in der Vergangenheit habe ich sie nach Browser-Installationen immer deaktiviert.
  • Nachfrage, welche Sicherheitslücken konkret gemeint sind; Hinweis, dass diese Implementierung sehr klein sei, verbunden mit starkem Vertrauen darauf, den Nutzern das bestmögliche Ergebnis zu liefern.
  • Frage, ob es eine Option wie --without-whip gibt, um das Feature bei Bedarf komplett aus dem Build auszuschließen; das wäre aus dieser Sicht optimal.
  • Da ffmpeg in der Vergangenheit viele Sicherheitsprobleme hatte, ist für die Verarbeitung von Nutzereingaben eine isolierte Umgebung immer am besten: etwa pro Aufgabe ein neues Docker-Image nur mit ffmpeg und seinen Abhängigkeiten starten; wenn auch Thumbnails oder Dokumente verarbeitet werden müssen, empfiehlt sich zusätzlich ClamAV, OpenOffice, ImageMagick usw. Außerdem sollten Server, die nutzergenerierte Dateien verarbeiten, möglichst in einem getrennten VLAN laufen oder auf AWS nur innerhalb von Security Groups betrieben werden. Das ist keine Kritik an einzelnen Projekten, sondern betont die inhärente Schwierigkeit binärer Formate und die Bedeutung proaktiver Schutzmaßnahmen. Siehe auch das 4chan-Beispiel; die ffmpeg-Sicherheitsseite ist hier.
• Frage, wie es um die Security-Audits von ffmpeg steht; auf der offiziellen Website wirkt das etwas reaktiv.
• Frage, ob man mit ffmpeg nun den Audio-Stream einer Jitsi-Videokonferenz aufzeichnen kann.
• Frage, ob jemand die WHIP-Unterstützung erfolgreich in einem FFmpeg-Source-Build aktiviert hat; es sei schwer, die richtigen ./configure-Optionen zu finden.
  • Hinweis, dass die benötigten Optionen --enable-muxer=whip und --enable-openssl sind.
• Ich kann es kaum erwarten, bis diese Funktion in Jellyfin ankommt.
  • Rückfrage, welchen funktionalen Nutzen das konkret für Jellyfin hätte.