FFmpeg 8.0 veröffentlicht

 (ffmpeg.org)
2 Punkte von GN⁺ 2025-08-23 | 1 Kommentare | Auf WhatsApp teilen
  • FFmpeg 8.0 "Huffman" ergänzt Vulkan-Compute-basierte Codecs sowie hardwarebeschleunigtes Decoding und Encoding und fügt mehrere neue Dateiformate und Filter hinzu
  • Die Infrastruktur wurde umfassend modernisiert, und auch Beitragsprozess und Codequalität wurden verbessert
  • Zu den wichtigen Fortschritten bei Audio- und Video-Codecs zählen die Stabilisierung des VVC-Decoders, ein xHE-AAC-Decoder sowie MV-HEVC- und LC-EVC-Unterstützung
  • FFmpeg spielt weiterhin eine zentrale Rolle bei der Weiterentwicklung von Open-Source-Multimedia-Technologie und treibt fortlaufende Funktionsverbesserungen und Sicherheitssteigerungen voran

Einführung in FFmpeg

  • FFmpeg ist ein vollständiges universelles Toolkit zur Multimedia-Verarbeitung und bietet eine flexible und leistungsstarke Lösung zum Aufnehmen, Konvertieren und Streamen von Audio und Video
  • Mit einfachen Befehlen wie ffmpeg -i input.mp4 output.avi lassen sich Video- und Audioverarbeitung ausführen

23. August 2025: Veröffentlichung von FFmpeg 8.0 "Huffman"

  • FFmpeg 8.0 "Huffman" wurde veröffentlicht. Nach mehreren Verzögerungen und einer Modernisierung der Infrastruktur ist dies die bislang umfangreichste Veröffentlichung des Projekts
  • Zu den neuen Funktionen gehören zusätzliche native Decoder für APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728 sowie erweiterte Unterstützung des VVC-Decoders für IBC, ACT und Palette Mode und Codecs wie das Vulkan-Compute-basierte FFv1 (Encoding und Decoding), ProRes RAW (nur Decoding)
  • Eingeführt wurden Vulkan-basiertes hardwarebeschleunigtes Decoding (z. B. VP9, VVC, H264/5) und Encoding (AV1, H264/5) sowie verschiedene neue Formate (MCC, G.728, Whip, APV) und Filter (colordetect, pad_cuda, scale_d3d11, Whisper usw.)
  • Neu hinzugekommen ist eine Familie von Decodern und Encodern auf Basis von Compute Shadern, die unter Vulkan 1.3 laufen. Die Architektur benötigt keine speziellen separaten Hardware-Beschleuniger und arbeitet identisch zur hwaccel API. Für die Nutzung der Encoder muss jeweils der neue Encoder angegeben werden; derzeit werden nur FFv1 (Encoding und Decoding) und ProRes RAW (Decoding) unterstützt. ProRes (bidirektional) und VC-2 (bidirektional) sind in Vorbereitung
  • Diese Architektur lässt sich nur auf für paralleles Decoding optimierte Codecs anwenden; künftig werden deutliche Leistungsverbesserungen und neue Einsatzmöglichkeiten wie nichtlineare Videobearbeitung und verlustfreie Aufzeichnung in weiteren Bereichen erwartet
  • Auch die Projektinfrastruktur wurde umfassend modernisiert. Der Mailinglisten-Server wurde vollständig ersetzt, und unter code.ffmpeg.org wird nun Forgejo-basierte Code-Zusammenarbeit unterstützt
  • Nutzerinnen und Nutzern wird ein Upgrade auf die neueste Version empfohlen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-23
Hacker-News-Kommentare

  • Dank an die FFmpeg-Entwickler und Mitwirkenden

    • Ich habe immer FFmpeg verwendet, wann immer ich Audio-/Video-Automatisierung brauchte, und die meisten Online-Video-Tools nutzen dieses Tool ebenfalls als Kern-Engine oder als UI-Wrapper.
    • Heute habe ich auch erfahren, dass es das Projekt FFmpeg.Wasm gibt (https://github.com/ffmpegwasm/ffmpeg.wasm).
    • Im Januar 2024 habe ich einmal die Frames eines Animationsfilms von 1993 in 15-Minuten-Abschnitten extrahiert, sie dann mit Real-ESRGAN-ncnn-vulkan (https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan) hochskaliert und die resultierenden Frames anschließend wieder zu 4K zusammengesetzt.
    • Ich dachte dabei, dass daraus mit einer UI vielleicht ein Tool wie das derzeit populäre Topaz AI hätte werden können.
    • Es wurde auch ein hochskaliertes Beispielbild geteilt (Beispielbild).
    • Selbst wenn ich ffmpeg nicht direkt nutze, verwende ich oft Tools, die es eingebettet haben.
      • Kürzlich habe ich alte Anime in niedriger Qualität, die ich von einer alten DVD extrahiert hatte, mit k4yt3x/video2x hochskaliert; die Installation war einfach und libffmpeg war integriert.
      • Beim Encoding konnte ich dieselben Argumente wie bei FFmpeg verwenden.
      • Um die optimalen Argumente auszuwählen, habe ich mit ffmpeg kurze Szenen mit mehreren Parametersätzen encodiert und anschließend wieder mit ffmpeg Standbilder extrahiert, um sie zu vergleichen.

  • Es freut mich, dass FFmpeg Video-Encoder und -Decoder auf Basis von Compute Shadern eingeführt hat.

    • Die in Hardware breit unterstützten Codecs sind im Wesentlichen H.264, H.265 und AV1, daher wäre es gut, wenn auch andere Codecs eine Plattformbeschleunigung bekommen könnten, selbst wenn sie etwas weniger effizient ist.
    • Der neue ProRes-Encoder wirkt nützlich für ein laufendes Projekt.
    • Ich kann nachvollziehen, warum breit genutzte allgemeine Codecs schwer zu unterstützen sind, da sie sich nicht gut für paralleles Decoding eignen.
    • Man müsste Zehntausende Threads nutzen, aber Datenabhängigkeiten zwischen Frames und zwischen Tiles machen die Parallelisierung nicht einfach.
    • Beim Encoder scheint es etwas mehr Spielraum zu geben als beim Decoder, aber etwas wie VP9 (https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) per Compute Shader zu encodieren, dürfte eine anspruchsvolle Aufgabe sein.

    • Noch einmal die Freude über die Umsetzung von Video-Encodern/-Decodern mit Compute Shadern.

      • Früher gab es nur standardisierte In-Silicon-Hardware-Schnittstellen, daher wurde ich ausgelacht, als ich fragte, ob Vulkan-basierte Encoder/Decoder allgemein nutzbar wären.
      • Dass solche Verbesserungen sogar auf älterer Hardware verfügbar sind, ist wirklich großartig; hoffentlich eröffnet das neue Wege für neue Codecs und generelle Qualitätsverbesserungen.

    • Ich habe die neuesten Decoder-Entwicklungen seit über zehn Jahren nicht mehr verfolgt, aber intuitiv würde ich erwarten, dass GPU-Beschleunigung besonders beim späteren Verarbeitungsschritt hilft, wenn die Daten in Pixel umgewandelt werden.

      • Die anfängliche Dekompression könnte auf der CPU erfolgen, danach würden die dekomprimierten Daten zur GPU übertragen, um die letzten Umwandlungsschritte auszuführen, etwa das Anwenden von Motion Vectors oder iDCT.
      • Wenn der fertige Frame bereits als GPU-Textur vorliegt, ist auch der Anzeige-Overhead gering.
      • Ich frage mich, wie sehr meine Intuition hier zutrifft.

    • Ich bin immer wieder erstaunt über das Talent der FFmpeg-Maintainer; es ist beeindruckend, dass sie solch schwierige Arbeit kostenlos leisten.

    • Diese Release Notes sind sehr interessant.

      • In den letzten Wochen habe ich einen ProRes-Decoder mit WebGPU-Compute-Shadern gebaut, und er läuft schnell genug; Apple wird vermutlich eigene Hardwarebeschleunigung verwenden.
      • Dieser Ansatz scheint auch gut zum neuen APV-Codec auf Android zu passen.
      • Die ProRes-Bitstream-Spezifikation wurde zwar bei SMPTE eingereicht, aber Informationen zu ProRes RAW waren schwer zu finden.
      • Dass nun software- und compute-basierte Implementierungen auftauchen, finde ich äußerst spannend; vermutlich haben die ffmpeg-Entwickler das per Reverse Engineering erschlossen.
      • Nach einem groben Blick in den Code scheint es sich nicht stark von normalem ProRes zu unterscheiden.
      • ProRes-Spezifikationsdokument

  • Jedes Mal, wenn ich FFmpeg nutze, bin ich beeindruckt, auch wenn ich dafür wieder im Handbuch nachschlagen oder mir von einem LLM helfen lassen muss, selbst dann, wenn ich eine GUI verwende, die aus visuellen Optionen den Befehl erzeugt.

    • Es scheint inzwischen das unverzichtbare Transcoding-Multitool geworden zu sein.
    • Die Einführung von Vulkan-1.3-basierter Verarbeitung halte ich für eine gute Entscheidung.
    • Gestern habe ich außerdem erfahren, dass auch Asahi Linux on Mac denselben Standard unterstützt.

    • Eine witzige Formulierung dazu: FFmpeg-Argumente seien das „ursprüngliche Prompt Engineering“.

    • LLMs und komplexe Kommandozeilen-Tools wie FFmpeg oder ImageMagick sind eine fantastische Kombination.

      • Es fühlt sich fast wie die perfekte UI/UX der Zukunft an: Man beschreibt einfach in natürlicher Sprache, was man tun möchte, und es wird direkt umgesetzt.
      • Als Beispiel wurde ein Szenario genannt, in dem alle Bilder eines Ordners auf eine bestimmte Größe zugeschnitten, die Sättigung angepasst, als TIFF gespeichert, zu einer Video-Schleife zusammengesetzt und anschließend noch für das Web encodiert werden.

    • LLMs funktionieren hervorragend als Interface für FFmpeg.

      • Es gibt viele Tools, die dabei helfen, FFmpeg in natürlicher Sprache zu nutzen, und es wurde auch ein eigenes Skript geteilt (https://github.com/jjcm/llmpeg).

  • Es wurde halb im Scherz, halb ernst gesagt, dass 50 % der Mühe beim Erstellen komplexer CLI-Befehle mit ffmpeg draufgehen und die anderen 50 % im Kampf mit Shell-Escaping.

    • Besonders schwierig sei Text-Escaping, wenn man Text in ein Video einblenden will.
    • Es wurde gefragt, ob jemand einen perfekten Weg gefunden hat, ffmpeg aus Python mit vielen Argumenten wie Filtern aufzurufen (r-strings? heredocs? usw.).

  • Es wurde gefragt, ob es ein gutes GUI-Frontend gibt, mit dem sich die vielen FFmpeg-Funktionen leicht nutzen lassen.

    • Manchmal braucht man nur ein Remuxing oder möchte lediglich Video-/Audiostreams mit demselben Codec zusammenführen.

    • Das Zusammenführen von Videos klingt einfach, hat aber in Wirklichkeit viele Variablen und Fallstricke.

      • Timebase, Start-Offsets, Frame-Cropping, FPS-Unterschiede, B-Frames, Open GOPs und weitere Faktoren können in bestimmten Wiedergabeumgebungen Probleme verursachen.
      • Auch bei Audio gibt es viele Variablen wie unterschiedliche Sampleraten.
      • Das Programm Lossless-Cut wurde erwähnt; seine Kompatibilitätsprüfung sei nützlich.
      • Noch besser sei es jedoch oft, das Video zuerst in MPEG-TS umzuwandeln und es dann zusammenzuführen, da dies viele Probleme umgeht und sich auf einer RAM-Disk schnell verarbeiten lässt.
      • Es wurde auch eine Beispielsequenz von ffmpeg-Kommandozeilen geteilt.

    • Handbrake erfüllt diese Rolle gut.

      • Vom Funktionsumfang her reicht es aus; es wirkt zwar etwas alt, ist aber weiterhin nützlich.

    • Mac-Nutzern wird ffWorks empfohlen (https://www.ffworks.net/index.html).

      • Die meisten Funktionen sind leicht zugänglich, und Batch-Verarbeitung sowie Presets werden unterstützt.
      • Der Entwickler bietet sehr engagierten Support, weshalb es zu den Lieblings-Apps zählt; es sei so wertvoll, dass sogar gespendet wurde.
      • Handbrake und Losslesscut seien ebenfalls großartig, aber auf anderen Plattformen gebe es offenbar keine App, die in Sachen Reifegrad mit ffWorks konkurrieren könne.

    • Für mich ist das beste Frontend ChatGPT.

      • Wenn man in natürlicher Sprache beschreibt, was man tun will, erzeugt es äußerst präzise ffmpeg-Befehle.

    • Es wird empfohlen, sich Lossless-cut anzusehen.

  • Es wurde ein Link geteilt, unter dem sich das FFmpeg-Changelog einsehen lässt (https://github.com/FFmpeg/FFmpeg/blob/master/Changelog).

  • Kurz gesagt: interessante Neuigkeiten.

    • Jemand fragte sich, ob dieses Video Satire oder ernst gemeint sei.

  • Es wurde die persönliche Meinung geäußert, dass ffmpeg vielleicht die am vierthäufigsten genutzte Bibliothek nach ssl, zlib und sqlite ist, unter der Annahme, dass Video im Jahr 2025 wirklich überall ist.

    • Dem wurde eher widersprochen, da Videoverarbeitung meist auf Servern nötig sei, die Medien ausliefern.

      • Es wurde erwähnt, dass die meisten Handys ihre Videos nicht mit ffmpeg verarbeiten.

    • curl könnte weiter oben liegen, und bei „SSL“ würden sich die Zahlen wegen der vielen Implementierungen verteilen.

    • Als Datenquelle wurden die fastly-Metrik-Logs der NixOS-Infrastruktur vorgeschlagen (https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md).

    • Es wurde vermutet, dass es einige Bibliotheken gibt, die häufiger genutzt werden als ffmpeg, etwa Qt, libpng oder libusb.

    • Auch die Paketstatistiken von Arch Linux könnten einen Blick wert sein (https://pkgstats.archlinux.de/packages).

  • Die Vulkan-Compute-Shader-Implementierung wirkt besonders bei FFv1 und ProRes RAW beeindruckend.

    • Da damit festverdrahtete Hardware-Decoder vollständig umgangen werden, stellt sich die Frage, wie sich das auf die Speicherbandbreite auswirkt.
    • Die kontextadaptive arithmetische Codierung von FFv1 scheint ihrem Wesen nach seriell zu sein und daher kaum beschleunigbar, weshalb die gemeldeten großen Geschwindigkeitsgewinne überraschen.
    • Es stellt sich die Frage, ob mehrere Symbole gleichzeitig oder auf Slice-Ebene parallelisiert werden und welche Trade-offs das ffmpeg-Team eingegangen ist, da arithmetische Codierung traditionell schwer auf GPUs zu beschleunigen ist.
    • Falls jemand Erfahrung mit dem Profiling dieser Implementierung hat, wäre es interessant, etwas über die Auslastung in der Entropie-Decoding-Phase und die Wahl der Bandbreite zu hören.

  • ffmpeg bildet die Grundlage für unglaublich viele Werkzeuge.

    • Der breiten Öffentlichkeit ist oft nicht bewusst, wie viel ffmpeg zur Medienbranche beigetragen hat.
    • Es ist ein Tool, zu dem ich immer greife, sobald Audio-/Video-Automatisierung nötig ist.