Metas Einsatz von FFmpeg: Das Geheimnis der Medienverarbeitung im großen Maßstab

• Meta führt zig Milliarden FFmpeg-Ausführungen pro Tag aus und hat den vollständigen Umstieg von einer internen Fork-Version auf Upstream-FFmpeg erfolgreich abgeschlossen
• Um die Funktionslücke zwischen interner Fork und Open-Source-Version zu schließen, wurden in Zusammenarbeit mit FFlabs und VideoLAN parallele Multi-Lane-Encoding-Verfahren und Funktionen für Echtzeit-Qualitätsmetriken im Upstream implementiert
• Pro Tag werden mehr als 1 Milliarde Video-Uploads verarbeitet; Multi-Resolution- und Codec-Encoding für die DASH-Wiedergabe erfolgt dabei mit einer einzigen FFmpeg-Kommandozeile
• Die in FFmpeg 6.0 bis 8.0 implementierte effiziente Threading-Struktur basiert auf Metas Design und verbessert die Encoding-Effizienz für alle Nutzer
• Der eigens entwickelte ASIC MSVP (Meta Scalable Video Processor) wurde über die standardisierte Hardware-API von FFmpeg integriert, um Konsistenz zwischen Software- und Hardware-Pipelines sicherzustellen
• Durch kontinuierliche Investitionen in das seit mehr als 25 Jahren entwickelte FFmpeg stärkt Meta zugleich neue Videoerlebnisse und die Stabilität seiner Plattform

---

Die Rolle von FFmpeg und Metas Herausforderungen

• FFmpeg ist ein branchenübliches Werkzeug für die Medienverarbeitung, das zahlreiche Audio- und Video-Codecs sowie Containerformate unterstützt und Medienbearbeitung und -konvertierung über komplexe Filterketten ermöglicht
• Meta führt die Binärdateien ffmpeg (Haupt-CLI) und ffprobe (Utility zum Abrufen von Medieneigenschaften) täglich zig Milliarden Mal aus; dabei gibt es zusätzliche Anforderungen, die über die Verarbeitung einzelner Dateien hinausgehen
• Lange Zeit war man auf eine interne Fork angewiesen und implementierte Funktionen wie threadbasiertes Multi-Lane-Encoding und die Berechnung von Echtzeit-Qualitätsmetriken selbst, weil diese damals im Upstream fehlten

Die Abspaltung der internen Fork und die Notwendigkeit der Rückkehr zum Upstream

• Die interne Fork hatte sich im Laufe der Zeit deutlich von Upstream-FFmpeg entfernt, wodurch die Lücke bei den Funktionsumfängen immer größer wurde
• Gleichzeitig boten neue FFmpeg-Versionen Unterstützung für neue Codecs und Dateiformate sowie Verbesserungen der Stabilität; um die Vielfalt der von Nutzern hochgeladenen Videoinhalte ohne Unterbrechung verarbeiten zu können, musste daher auch die aktuelle Open-Source-Version parallel unterstützt werden
• Da es immer schwieriger wurde, bei Rebases interner Änderungen Regressionen zu vermeiden, arbeitete Meta mit FFmpeg-Entwicklern, FFlabs und VideoLAN zusammen, um die interne Fork vollständig aufzugeben und nur noch die Upstream-Version zu verwenden

Aufbau effizienter Multi-Lane-Transkodierung (VOD und Livestreaming)

• Wenn Nutzer ein Video hochladen, wird ein Satz von Multi-Encoding-Ausgaben für die DASH- (Dynamic Adaptive Streaming over HTTP) Wiedergabe erzeugt; dabei entstehen Encodings mit jeweils unterschiedlicher Auflösung, unterschiedlichem Codec, unterschiedlicher Framerate und unterschiedlicher Qualitätsstufe
  • Der Videoplayer in der App kann je nach Signalen wie dem Netzwerkzustand in Echtzeit zwischen den Encodings umschalten
• Der einfachste Ansatz wäre, jede Lane mit einer eigenen FFmpeg-Kommandozeile nacheinander zu verarbeiten; selbst bei paralleler Ausführung ist das jedoch ineffizient, weil jeder Prozess doppelte Arbeit ausführt, etwa wiederholtes Decoding und Prozess-Start-Overhead
• Wenn Frames in einer einzigen FFmpeg-Kommandozeile nur einmal decodiert und anschließend an die jeweiligen Output-Encoder weitergereicht werden, lassen sich doppelte Decoding-Arbeit vermeiden und der Prozess-Start-Overhead senken
  • Da täglich mehr als 1 Milliarde Video-Uploads verarbeitet werden, führen selbst kleine Einsparungen pro Prozess insgesamt zu erheblichen Effizienzgewinnen
• Metas interne Fork bot zusätzlich Optimierungen für paralleles Video-Encoding: Während bestehendes FFmpeg bei mehreren Encodern pro Frame seriell arbeitete, wurden alle Encoder-Instanzen parallel ausgeführt, um ein höheres Maß an Parallelität zu erreichen
• Dank Beiträgen von FFmpeg-Entwicklern, darunter FFlabs und VideoLAN, wurde ab FFmpeg 6.0 ein effizienteres Threading eingeführt und in 8.0 vollendet
  • Es wurde direkt von der Architektur in Metas interner Fork beeinflusst und gilt als das komplexeste FFmpeg-Refactoring seit Jahrzehnten
  • Davon profitieren alle FFmpeg-Nutzer durch effizienteres Encoding

Echtzeit-Qualitätsmetriken (Livestreaming)

• Metriken für visuelle Qualität drücken die wahrgenommene Bildqualität numerisch aus und werden verwendet, um durch Kompression verursachte Qualitätsverluste zu quantifizieren
  • Referenzmetriken: vergleichen das Original-Encoding mit dem verzerrten Encoding
  • No-Reference-Metriken: bewerten die Bildqualität ohne Original
• FFmpeg kann Qualitätsmetriken wie PSNR, SSIM und VMAF mit zwei bereits vorhandenen Encodings nach Abschluss des Encodings in einer separaten Kommandozeile berechnen, doch beim Livestreaming ist eine Echtzeitberechnung erforderlich
• Durch das Einfügen eines Video-Decoders hinter dem Video-Encoder jeder Output-Lane lassen sich die Frame-Bitmaps nach Anwendung der Kompression gewinnen und mit den Frames vor der Kompression vergleichen, sodass Qualitätsmetriken für jede Encoding-Lane in Echtzeit innerhalb einer einzigen FFmpeg-Kommandozeile berechnet werden können
• Seit FFmpeg 7.0 ist dank Beiträgen von Entwicklern bei FFlabs und VideoLAN das "In-Loop"-Decoding aktiviert, wodurch die Abhängigkeit von der internen Fork für diese Funktion vollständig entfällt

Kriterien für Upstream-Beiträge und intern exklusive Patches

• Funktionen wie Echtzeit-Qualitätsmetriken und effizientes Threading verbessern die Effizienz zahlreicher FFmpeg-basierter Pipelines innerhalb und außerhalb von Meta und wurden deshalb in den Upstream eingebracht
• Dagegen bleiben Patches, die stark auf Metas Infrastruktur zugeschnitten und nur schwer zu verallgemeinern sind, intern
• FFmpeg unterstützt hardwarebeschleunigtes Decoding, Encoding und Filtering für NVIDIA NVDEC/NVENC, AMD UVD, Intel QSV und weitere Plattformen über standardisierte APIs
• Auch Metas eigener Video-Transcoding-ASIC MSVP (Meta Scalable Video Processor) wurde über dieselben standardisierten APIs unterstützt, sodass auf verschiedenen Hardwareplattformen gemeinsame Werkzeuge genutzt werden können
  • Da MSVP nur in Metas interner Infrastruktur eingesetzt wird, haben externe FFmpeg-Entwickler keinen Hardwarezugang zum Testen und Validieren; deshalb bleibt dieser Teil ein interner Patch
  • Beim Rebase auf aktuelle FFmpeg-Versionen werden umfassende Validierungen durchgeführt, um Robustheit und Korrektheit sicherzustellen

Kontinuierliche Investitionen in FFmpeg

• Mit Multi-Lane-Encoding und Echtzeit-Qualitätsmetriken wurde die interne Fork in allen VOD- und Livestreaming-Pipelines vollständig abgeschafft
• Dank der standardisierten Hardware-API von FFmpeg lassen sich der MSVP-ASIC und softwarebasierte Pipelines mit minimaler Reibung parallel unterstützen
• Meta plant, über Partnerschaften mit Open-Source-Entwicklern weiter kontinuierlich in FFmpeg zu investieren, das seit mehr als 25 Jahren aktiv entwickelt wird, wovon Meta, die Branche und die Nutzer profitieren

[GN⁺]

Hacker-News-Kommentare

• Als der interne Fork zunehmend veraltet war, haben wir mit den FFmpeg-Entwicklern zusammengearbeitet, um die benötigten Funktionen in das offizielle FFmpeg zu integrieren
  Dadurch konnten wir die interne Version vollständig aufgeben und nur noch die Upstream-Version betreiben
  Manche sagen zwar, man hätte „mehr beitragen können“, aber das Wesen von Open Source ist, dass alle vom Nutzen profitieren

  • Ich denke, man kann nicht bestreiten, dass Meta zur Community beiträgt
    Durch zahlreiche Projekte wie React und React Native profitieren wir bereits davon
  • Wenn solche Funktionen aber aus den Anforderungen extrem großer Unternehmen entstehen, spüren die meisten Nutzer den Nutzen kaum
    Letztlich begünstigt so eine Struktur nur die Seite, die ohnehin Macht hat
  • Es ist eindeutig eine positive Veränderung, aber im Hintergrund gab es eine Phase, in der interne Vorteile Vorrang hatten
    Trotzdem wirkt es für Meta als Unterscheidungsmerkmal in der Branche, dass das Unternehmen viel für das Open-Source-Ökosystem veröffentlicht hat
  • Man sollte nicht vergessen, dass kein Big-Tech-Unternehmen ohne eine Open-Source-Basis hätte existieren können
  • Open-Source-Beiträge an sich sind gut, aber mir gefiel der Ton des Blogposts nicht
    Formulierungen wie „jetzt haben wir es endlich in den Upstream integriert“ wirkten, als wolle man frühere Versäumnisse schönreden
    Marketing-Sprache in einem Technikblog ist aus Lesersicht störend

• Hoffentlich wird Fabrice Bellard bei seinem Ruhestand angemessen entlohnt
  Dank seiner Software haben unzählige Unternehmen Geld verdient

• Es ist gut, dass neue FFmpeg-Versionen verschiedene Codecs und Formate unterstützen,
  aber bei einem Umfang, in dem Meta es täglich Milliarden Male ausführt, frage ich mich, ob sie sich an solchen Verbesserungen kontinuierlich beteiligt haben

  • [gelöschter Kommentar]

• Dass es täglich zig Milliarden Male ausgeführt wird, ist wirklich ein gewaltiger Maßstab
  Ich merke schon Overhead, wenn ich automatisierte Videozusammenstellungen nur ein paar Tausend Mal pro Tag laufen lasse
  Dank der Funktion single-decode multi-output sank die Verarbeitungszeit um 40%

  • In diesem Maßstab dürfte auch die RAM-Nutzung jenseits aller Vorstellung liegen
    Glücklicherweise ist durch die zuletzt gefallenen Speicherpreise das Kosten-Nutzen-Verhältnis von Open-Source-Verbesserungen noch attraktiver geworden

• Der Ansatz, Encoder-Instanzen parallel laufen zu lassen, um die Parallelität zu erhöhen, ist vernünftig
  Aber ich würde gern eine Funktion zur Zeitachsen-Parallelisierung (time-axis parallelization) sehen
  Wenn man das Eingabevideo an Keyframes aufteilt und parallel encodiert, könnte man die Geschwindigkeit ohne Qualitätsverlust erhöhen

  • Aber kann man die Positionen der Keyframes im Voraus vorhersagen?
    Normalerweise platziert der Encoder sie dynamisch für mehr Effizienz, daher könnte eine Aufteilung im Vorfeld schwierig sein
  • Ich frage mich, ob sich die Bewegungsanalyse, die der Encoder bei der Analyse von P-/B-Frames durchführt, einmal berechnen und für mehrere Encodings wiederverwenden ließe

• Vielen Dank an das Meta-Team für die Beiträge zu ffmpeg und ffprobe
  Ich hoffe, sie ziehen künftig auch finanzielle Unterstützung für Code-Qualität, Dokumentation und Community-Veranstaltungen in Betracht

• Die Formulierung „der interne Fork wurde zunehmend alt“ ist so nachvollziehbar
  Übrigens werden in FFmpeg 8 HDR- und SDR-Farbzuordnung perfekt verarbeitet

  • Früher hatte ich wegen Problemen mit dem automatischen Kopieren von Metadaten zu kämpfen, daher freue ich mich sehr, dass das jetzt gelöst ist
  • Schön, nach langer Zeit wieder davon zu hören, und die Entwicklung ist beeindruckend

• Interessant ist die Meldung, dass Deutschlands Sovereign Tech Fund an FFmpeg gespendet hat

  • Der deutsche STF hat etwa 150.000 US-Dollar gespendet, aber allein ein Jahr Personalkosten für einen Meta-Ingenieur dürfte mehr als das Doppelte betragen
    Vermutlich hat Meta ein eigenes Team für Media Encoding und leistet Beiträge im Wert von mehr als 1 Million US-Dollar pro Jahr
  • Das offizielle FFmpeg-Konto erwähnte jedoch: „Wir schätzen Metas Unterstützung, aber sie ist nicht nachhaltig genug“
    Zugehörigen Tweet ansehen
  • Ich frage mich, wie viel Meta tatsächlich gespendet hat
    Der deutsche STF soll 2024/2025 €157.580 bereitgestellt haben
  • Etwas ironisch ist es schon, dass Meta Milliarden verdient und trotzdem weniger als ein staatlicher Fonds spendet
  • [gelöschter Kommentar]

• Zum Glück verarbeiten die FFmpeg-Server nur leichte Inhalte, sodass sie durchhalten
  Bei schwerem Videomaterial wären sie wohl überlastet gewesen

• Derselbe HN-Post wurde schon vor 6 Tagen eingereicht
  Ich verstehe nicht, warum man für diesen Hinweis Downvotes bekommt

  • Soweit ich weiß, sind Wiedereinreichungen in Ordnung, solange nicht derselbe Nutzer sie wiederholt einreicht
  • [gelöschter Kommentar]