FFmpeg führt nach Jahrzehnten mit dem „komplexesten Refactoring“ Multithreading in der CLI ein

Unterstützung für Multithreading in der FFmpeg-CLI

• Die Unterstützung für Multithreading in der FFmpeg Command-Line Interface (CLI) wurde in FFmpeg Git zusammengeführt.
• Dies ist eine Änderung vor der Veröffentlichung von FFmpeg 7.0 Anfang nächsten Jahres und stellt eine große Verbesserung für das wichtige Open-Source-Projekt dar, das weithin für Video-Transcoding genutzt wird.
• Da Multi-Core-Prozessoren heute allgemein verbreitet sind, ist diese Verbesserung äußerst vorteilhaft.

Komplexe Refactoring-Arbeiten

• FFmpeg-Entwickler beschrieben diese Multithreading-Arbeit in einer aktuellen technischen Ankündigung als „eines der komplexesten Refactorings, die in Jahrzehnten in der FFmpeg-CLI durchgeführt wurden“.
• Die Entwickler bitten die Nutzer um Tests und fordern dazu auf, gefundene Probleme an FFmpeg Trac zu melden.

Umgesetzte technische Änderungen

• Der zusammengeführte Patch umfasst das Hinzufügen einer threadbewussten Transcoding-Scheduling-Infrastruktur, das Verschieben der Kodierung in einen separaten Thread sowie mehrere weitere Low-Level-Änderungen.
• Die Umstellung von FFmpeg auf eine Thread-Architektur bedeutet, dass jede Komponente (Demuxer, Decoder, Filter, Encoder, Muxer) zwar bereits in einem separaten Thread lief, nun aber tatsächlich parallel ausgeführt werden kann.

Meinung von GN⁺

• Die Unterstützung für Multithreading in FFmpeg ist ein wichtiger Fortschritt, der die Effizienz von Video-Transcoding-Aufgaben deutlich verbessern kann.
• Diese komplexen Refactoring-Arbeiten stellten die Entwickler vor viele Herausforderungen und zeigen, dass sich FFmpeg kontinuierlich an moderne Computing-Umgebungen anpasst und weiterentwickelt.
• Für Nutzer und Entwickler wird es interessant sein zu beobachten, welche Auswirkungen diese Änderung auf die tatsächliche Leistung haben wird.

[GN⁺]

Hacker-News-Kommentare

• Theorie zur Optimierung von Multithreading/-processing

  • Früher dauerte es ziemlich lange, ein einzelnes Bild einzulesen, zu verarbeiten und zu rendern, aber durch Fortschritte bei Hardware und Software geht das heute deutlich schneller.
  • Früher war es effizient, wenn mehrere Worker an einem Frame arbeiteten, heute kann jedoch ein einzelner Worker einen Frame oft effizienter verarbeiten, als wenn mehrere Worker dafür eingesetzt werden.
  • Moderne Systeme unterscheiden sich völlig von den Systemen, als FFmpeg ursprünglich entstand, daher muss neu darüber nachgedacht werden, wie Workloads definiert, geplant, verteilt, nachverfolgt und anschließend zum Endergebnis zusammengeführt werden.
  • Lob dafür, dass das FFmpeg-Team sich dieser Herausforderung gestellt hat. FFmpeg sei ein Höhepunkt der Open-Source-Infrastruktur und ein wesentlicher Baustein, auf dem unsere Zivilisation aufbaut.

• Aufzeichnung des Vortrags bei der VDD@Dublin-Veranstaltung

  • Es wurde nach einer Aufzeichnung des Vortrags gesucht, aber weder auf der Website des Autors noch hier ließ sie sich leicht finden.
  • Update: Auf YouTube gefunden!

• Überlegungen zur Verbesserung der Multicore-Leistung

  • Aktuelle Encoder verwenden mehrere Threads, um gleichzeitig denselben Frame zu verarbeiten. Üblich ist es, den Frame in mehrere Bereiche aufzuteilen und jeden Thread einen bestimmten Bereich bearbeiten zu lassen.
  • Als Alternative wird vorgeschlagen, Keyframe-Segmente unabhängig voneinander zu verarbeiten. Damit ließe sich ein Codec auf allgemeine und effiziente Weise parallelisieren, ohne den Verlust an Kompressionseffizienz durch die Aufteilung eines Frames in Bereiche oder den Kommunikations-Overhead zwischen Threads.
  • Ein Problem bei diesem Ansatz ist, dass Frames im Umfang von N*Keyframe-Intervall in den Speicher geladen werden müssen und zusätzlicher Speicher-Overhead für das Kodieren von N Frames entsteht.
  • In vielen Fällen scheinen diese Nachteile jedoch kein großes Problem zu sein. Meist ist es akzeptabel, viel RAM zu nutzen und mit festem Keyframe-Abstand auszugeben.
  • Durch die Kombination von Parallelisierung innerhalb eines Frames und der Parallelisierung über Keyframe-Segmente hinweg lässt sich ein hoher Grad an Parallelität erreichen, während Qualitätsverluste minimiert werden.

• Die Herausforderung kontinuierlicher Rebase-Arbeit

  • Die täglich eingehenden Änderungen fortlaufend zu rebasen, war eine beträchtliche Herausforderung.
  • Jetzt, da es in FFmpeg integriert ist, dürfte die Arbeit künftig deutlich einfacher werden.
  • Ein großer Erfolg, der erheblich zur Geschwindigkeitssteigerung beitragen wird.

• Erwartete Verbesserung der Startzeit für Virtual-Display-Buffer-Streaming mit FFmpeg

  • Im Projekt LLMStack wird FFmpeg verwendet, um Browser-Video zu streamen.
  • Derzeit gibt es bei jedem Aufruf eines Tools eine spürbare Verzögerung beim Hochfahren der Pipeline.
  • Die Verbesserungen in FFmpeg werden bei diesen Optimierungen definitiv helfen.

• Werbung für einen FFmpeg-C-API-Kurs

  • Es wird ein Kurs beworben, der auf Udemy die FFmpeg C API lehrt.

• Neugier auf die FFmpeg-Codebasis

  • Es besteht keine große Vertrautheit mit der FFmpeg-Codebasis, aber es wird gefragt, wie Änderungen schrittweise vorgenommen werden konnten, ohne einen riesigen Commit zu erzeugen.
  • Laut Präsentation gab es 700 Commits; es wird gefragt, ob das ein separater Branch war oder ob die Änderungen nach und nach in das Projekt gemergt wurden.

• Perspektive eines Cloud-Service-Betreibers

  • Wenn man einen Cloud-Service wie Netflix betreibt, laufen auf jeder Maschine ohnehin bereits Tausende von FFmpeg-Prozessen, also ist das im Wesentlichen schon Multicore-Arbeit.

• Geteilte Erfahrungen mit threadbasierter Filterverarbeitung in VapourSynth

  • Seit fast 10 Jahren wird die threadbasierte Filterverarbeitung in VapourSynth geschätzt.
  • Die Verbesserungen in FFmpeg sind zwar großartig, werden aber am Workflow aus VapourSynth-Preprocessing + av1an-Encoding für „qualitatives“ Video-Encoding wohl nicht viel ändern.

• Frage zur Multicore-Unterstützung von FFmpeg

  • Es wird gefragt, ob FFmpeg nun bei allen enthaltenen Codecs Multicore nutzen kann.
  • Für einen Audio-Hosting-Service wird FFmpeg verwendet, um mit LAME MP3 zu kodieren, und eine kürzere Kodierzeit bei langen Dateien wäre wünschenswert.