FFmpeg führt eine Multithread-Transcoding-Pipeline ein

 (ffmpeg.org)
2 Punkte von GN⁺ 2023-11-07 | 1 Kommentare | Auf WhatsApp teilen
  • Multithread-Transcoding in der FFmpeg-CLI wurde nach rund 2 Jahren Arbeit und mehr als 700 vorbereitenden Commits erstmals in einer ersten „voll funktionsfähigen“ Form vorgestellt
  • Wegen des großen Änderungsumfangs besteht weiterhin die Möglichkeit, dass einige Funktionen beschädigt wurden; vor einem tatsächlichen Merge bleiben Tests und Reviews die zentrale Aufgabe
  • -fix_sub_duration_heartbeat kann wegen der Synchronisationsannahmen zwischen Decoder sowie Encoder und Muxer bei asynchroner Ausführung nichtdeterministisches Verhalten kaum vermeiden
  • Der Threading-Overhead ist meist gering, bei Aufgaben mit sehr wenig Arbeit pro Paket können die Kosten den Performancegewinn jedoch spürbar übersteigen
  • Wenn der Flaschenhals nicht auf eine einzelne Komponente konzentriert ist und die einzelnen Komponenten nicht bereits selbst multithreaded sind, können sich in Multicore-Umgebungen CPU-Auslastung und tatsächliche Verarbeitungszeit deutlich verbessern

Kernpunkte des FFmpeg-CLI-Multithreading-Patches

  • Nach etwa 2 Jahren Arbeit und mehr als 700 vorbereitenden Commits wurde die erste „fully functional“-Version der multithreaded FFmpeg-CLI als Patch-Set veröffentlicht
  • Angesichts des großen Änderungsumfangs besteht die Möglichkeit unentdeckter Defekte, daher sind Tests und Reviews auf Basis realer Nutzungsszenarien erforderlich
  • Im Allgemeinen ist der Threading-Overhead gering, bei Workloads mit sehr wenig Arbeit pro Paket kann er jedoch relevant werden
  • Wenn das Transcoding nicht von einer einzelnen Komponente dominiert wird und die einzelnen Komponenten nicht bereits durch eigenes Multithreading ausgelastet sind, können sich CPU-Auslastung und Laufzeit auf Multicore-Systemen verbessern

Funktionsgrenzen und bekannte Probleme

  • Die Option -fix_sub_duration_heartbeat setzt in der aktuellen Struktur Synchronisation zwischen getrennten Komponenten voraus
    • Der Zielablauf ist eine Synchronisation vom Encoder und Muxer zum Decoder
    • Wenn jede Komponente asynchron ausgeführt wird, wird das Verhalten grundsätzlich nichtdeterministisch
    • Auch derzeit ist das Verhalten schwer vorhersehbar, aber bei Ausführung mit derselben Option sind die Ergebnisse zwischen einzelnen Läufen deterministisch
    • Im Patch 16/24 wird diese Option deaktiviert; es wird ein besserer Umgang damit benötigt

Aufbau des 24-teiligen Patch-Sets

  • Das Patch-Set besteht aus insgesamt 24 Patches
    • 01-09/24 sind vorbereitende Korrekturen und könnten vor dem Rest der Serie gepusht werden
    • 10-17/24 verlagern Encoding und Filtering in Threads und führen die nötigen vorbereitenden Änderungen durch
      • Das Threading in dieser Phase ist ein „falsches“ Threading, bei dem der Main-Thread auf den Abschluss anderer Threads wartet; echte parallele Ausführung ist das also nicht
      • Da der temporäre Overhead groß sein oder einige Corner Cases beschädigt werden könnten, ist es sinnvoller, erst nach Fertigstellung des gesamten Sets zu pushen
    • 18/24 ist der größte einzelne Patch und fügt den Transcode-Scheduler hinzu, funktioniert zu diesem Zeitpunkt aber noch nicht tatsächlich
    • 19-24/24 stellen einzelne Komponenten auf die Verwendung des Schedulers um
      • Zur Review wurden sie getrennt, für den finalen Push sollten sie jedoch zusammengeführt werden
  • Zugehörige Materialien finden sich im aktuellen VDD-Vortragsvideo und im Branch ffmpeg_threading

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-07
Hacker-News-Meinungen

  • Auf einem 4-Core-ARM-Server wurde es etwa 2× schneller, und der Parallelisierungs-Overhead scheint nicht groß zu sein.
    ffmpeg_threading/ffmpeg brauchte 7,771 Sekunden, das bisherige ffmpeg 13,841 Sekunden; die CPU-Auslastung lag bei 218 % bzw. 114 %.

    • Hier wurde auf der Decode-Seite keine Hardwarebeschleunigung genutzt, und die Videoausgabe war ebenfalls entfernt.
      Ich frage mich, wie es auf einer NVIDIA-Karte wäre, wenn sowohl Video-Decoding als auch -Encoding hardwarebeschleunigt laufen: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • Ich frage mich, welche Teile multithreaded werden. Videokompression ist bereits multithreaded, bei der Dekompression von Video weiß ich es nicht genau.
      Die übrigen Arbeiten dürften von den Performance-Kosten her relativ klein sein; daher ist die Verbesserung zwar willkommen, aber ich erwarte, dass der praktische Effekt ziemlich begrenzt sein wird.

  • Es wäre wohl besser gewesen, statt des Tweets https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... zu verlinken.
    Der Kern des Tweets ist letztlich auch dieser Link.

    • Inzwischen kann man es einfach Post nennen. Es gibt auch keine 280-Zeichen-Grenze mehr; lange Texte sind nur standardmäßig eingeklappt.

  • Um das zu verstehen, sollte man sich Antons Vortrag auf den VideoLAN Dev Days 2023 ansehen: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • Der Vortrag war gut, und ich frage mich, was mit den unter „Future directions“ genannten dynamic pipelines und „scripting (Lua?)“ gemeint war.
      Das lässt mich an eine Richtung denken, in der sich Property-Animationen mächtiger handhaben lassen.
    • Mit den Problemen rund um Extras, die etwa bei Minute 33 auf der Folie zu sehen waren, habe ich wirklich sehr oft zu tun gehabt.
    • Ich würde mir den Vortrag unbedingt ansehen, aber die Audioqualität ist so schlecht, dass es schwerfällt, sich zu konzentrieren. Ich weiß nicht, wie man das heutzutage noch so gründlich verhunzen kann.
    • Ich weiß nicht, was daran schwer zu verstehen sein soll. Wird Multithreading im Bereich Video-Transcoding in einem anderen Sinn verwendet?

  • Der Tweet führt zu http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655... und verweist dort wiederum auf den Code https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading

    • Der Tweet verlinkt auf die Mailingliste, die offizielle Quelle des Patchsets. Um weiterzulesen, kann man „Next in Thread“ auswählen.

  • Ich frage mich, ob das automatisch angewendet wird oder ob man komplizierte Kombinationen von Kommandozeilenparametern zusammenstellen muss.

  • Ich frage mich, ob es Videoschnittsoftware gibt, die ffmpeg nutzt.
    Ich hatte einmal überlegt, etwas zu bauen, das Formen in SVG zeichnet und ffmpeg verwendet, eine UI davor setzt oder nur Text hinzufügt, habe aber nie angefangen.
    Avidemux fühlt sich ein bisschen so an; intern ist ffmpeg ziemlich roh, und da es nicht für den Zugriff aus einer GUI heraus gedacht ist, dürften darauf basierende Editoren träge, merkwürdig und schwer zu warten sein.
    So etwas wie ein modularer Editor mit Kommando-Deskriptor oder Pipeline-Viewer, der eine Vorschau erzeugt, scheint möglich.
    ffmpeg ist mächtig, aber dass es nur über die Kommandozeile genutzt wird, hält manche Nutzer ab. Früher habe ich ein Python-Skript geschrieben, das eine zufällige Anzahl von Clips entgegennahm und mit dem xstack-Filter ein Mosaik erzeugte; das war nicht einfach.

  • Es wäre schön, wenn die kleinen Transcoding-Jobs, die ich für Plex mache, schneller würden.
    Meine Grafikkarte unterstützt kein Hardware-Transcoding, daher freue ich mich darauf.

  • Ich habe nach Möglichkeiten gesucht, Transcoding zu beschleunigen; eine war GPU-Beschleunigung, die andere, die Zahl der Threads zu erhöhen.
    Allerdings ist es schwierig, die optimale Thread-Zahl zu finden.

    • Könnte man zur Suche nach dem Optimum nicht Hyperparameter-Optimierung verwenden? Mit Tools wie Sherpa oder Scikit-optimize kann man Suchräume wie Thread-Zahl, Eingabetyp und CPU-Typ durchgehen.
    • Für die meisten Aufgaben sollte man die Thread-Zahl auf die Zahl der vCPUs setzen. Hyperthreaded Cores zählen also als 2.
      Wenn möglich, ist GPU-Beschleunigung allerdings deutlich besser.

  • Ich frage mich, wie die Lizenzanforderungen bei großen ffmpeg-Deployments aussehen. In welchen Fällen fallen Kosten an?

    • „FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.“
      http://ffmpeg.org/legal.html
      Es ist also kostenlos, aber wenn man bestimmte Module nutzt, kann es beim Mischen mit proprietärem Code problematisch werden.
    • Die übliche Art, ffmpeg in proprietärer Software zu verwenden, besteht darin, die verwendete ffmpeg-Version statisch zu kompilieren und in die ausführbare Datei zu linken oder sie von der proprietären Software als separate ausführbare Datei aufrufen zu lassen.

  • Schön zu sehen, dass FFmpeg besser wird. Hoffentlich sehen wir bald auch Unterstützung für Dolby AC4.