Wie kann man beim Konvertieren einer Reihe von PNG-Dateien mit ffmpeg die RGB-Farbe so weit wie möglich bewahren?

Question

Ich habe 950 PNG-Dateien, die zu Einzelbildern in einer 38 Sekunden langen Videospur mit 25 Bildern pro Sekunde werden sollen. Die Dateinamen sind bis auf die Sequenznummer identisch, wie in solchen Fällen üblich.

Ich möchte aus dieser Reihe von PNG-Bildern, die ich habe, einen Container in einem weithin unterstützten Format erstellen, idealerweise WebM, wenn alle Kriterien damit erfüllt werden können, oder beispielsweise MPEG-4, mit einem Codec, der von modernen Browsern für die Wiedergabe unterstützt wird. Das Problem besteht darin, dass die Farben verschoben sind und die Hintergrundfarbe im dekodierten Video nicht mehr mit demselben RGB-Tripel übereinstimmt, das aus der Hintergrundfarbe in den PNG-Bildern abgetastet wurde. Dies führt dazu, dass das Video auf meiner HTML-Seite, in die das Video eingebettet ist, aus dem vorgesehenen Hintergrund herausragt.

Ich habe es auf die einfache Art versucht:

ffmpeg -f image2 -i image%03d.png output.webm

das mir tatsächlich eine VP9-Videospur mit 25 fps lieferte, die in einem WebM-Container verpackt war.

Die PNG-Bilder sind im Animationsstil gehalten, mit einfarbigem Hintergrund und einfachen Formen, die für den Vordergrund animiert werden. Sie scheinen farbig zu seinunmarkiert(das sagt mir Adobe Bridge, ich nehme an, das bedeutet, dass kein eingebettetes Farbprofil vorhanden ist oder ein Verweis auf eines vorliegt.) Das Problem bei meinem obigen Versuch besteht darin, dass, obwohl der Container in Chrome wiedergegeben wird, die aus dem PNG-Bild mit dem RGB-Triplet abgetastete Hintergrundfarbe #ED4D56optisch nicht mit der Hintergrundfarbe übereinstimmt, die im wiedergegebenen Video erscheint.

Ist dies eine unvermeidbare Nebenwirkung der Farbkonvertierung von RGB zu YUV (Kodierung) zu RGB (Wiedergabe)? Gibt es eine Möglichkeit, dies abzumildern? Ich bestehe nicht darauf, dass die Frames in der Videospur mit RGB kodiert werden. Ich nehme an, YUV ist in Ordnung, solange ein moderner Browser, der diese Frames wiedergibt, beim Dekodieren und Anzeigen der Frames dasselbe (innerhalb einer vernachlässigbaren Fehlerspanne) RGB-Tripel erzeugt.

Meine Frage ist, mit welcher Befehlszeile ffmpegich versuchen kann, dies zu mildern. Ich bin offen dafür, den Videocodec und das Pixelformat zu ändern, die Farbverwaltung in ffmpeg zu aktivieren, falls vorhanden, usw.

Answer 1

Ich hatte kürzlich eine sehr ähnliche Aufgabe und würde sagen, dass es noch immer keine perfekte Lösung gibt (Stand Oktober 2018). Dies ist in der Tat der Nebeneffekt der unpräzisen Farbkonvertierung von RGB zu YUV zu RGB. Sogar einige „verlustfreie“ Varianten von Codecs (z. B. libvpx-vp9 -lossless) erzeugen aufgrund des YUV-Farbraums verzerrte Farben.

• Wenn nicht exakte Farben akzeptabel sind, dannlibvpxCodec kann ganz gute Arbeit leisten:

  ffmpeg -r 25 -i image%03d.png -c:v libvpx -crf 4 -b:v 0 output.webm
  

  Mit diesen Einstellungen kam es zu einer vernachlässigbaren Farbverschiebung oder bei einigen Frame-Sätzen wurden sogar die exakten Farben wiedergegeben. VPx-Codecs werden weitgehend unterstützt (alle gängigen Browser außer IE und Safari) und erzeugen eine angemessene Dateigröße.

• Wenn die exakten Farben unbedingt erforderlich sind, müssen wir die Farbraumkonvertierung vermeiden. Die einzige browserübergreifende Lösung, die mir eingefallen ist, ist die Verwendung vonanimiertes PNGBilder. ffmpegbietet nur sehr grundlegende Unterstützung für Apng, daher ist es besser, andere Tools zu verwenden, z apngasm. B.:

  apngasm output.png image001.png 1 25
  

  es funktioniert überall außer in IE und Edge (dort wird auf das statische erste Bild zurückgegriffen). Die Dateigrößen sind riesig, aber das ist der Preis für die wirklich verlustfreie Kodierung.

• Derlibx264rgbCodec sollte auch erwähnt werden - seine VerwendungWille die richtige Art und Weise sein, die genauen RGB-Farben zu kodieren, wenn/falls Browser dies unterstützen.