So erstellen Sie mit FFMPEG eine unkomprimierte AVI-Datei aus einer Reihe von 1000 PNG-Bildern

Wie kann ich mit FFMPEG eine unkomprimierte AVI-Datei aus einer Reihe von 1000 PNG-Bildern erstellen?

Mit diesem Befehl habe ich eine input.aviDatei in eine Reihe von PNG-Frames konvertiert :

ffmpeg -y -i input.avi  -an -vcodec png  -s 1024x768 pic%d.png`

Jetzt muss ich wissen, wie man aus all diesen PNG-Frames ein unkomprimiertes AVI-Video erstellt. Ich habe es versucht:

ffmpeg -i pic%d.png -y -f avi -b 1150 -s 1024x768 -r 29.97 -g 12 -qmin 3 -qmax 13 -ab 224 -ar 44100 -ac 2 test.avi

Das resultierende Video verliert jedoch im Vergleich zum ursprünglichen AVI-Format erheblich an Qualität.

Es gibt verschiedene Möglichkeiten, um eine "unkomprimierte" AVI-Datei herauszuholen ffmpeg, aber ich vermute, Sie meinen tatsächlich "verlustfrei". Wie Sie sehen werden, haben beide Begriffe in ihren Definitionen einiges an Spielraum.

Ich werde diese Diskussion mit der 720p HD-Version von Big Buck Bunny verankern , da es sich um ein frei verfügbares Video handelt, mit dem wir alle testen können und das Ergebnisse liefert, die wir vergleichen können. Die Rohdatenrate von 1280 × 720p-Video bei 24 fps entspricht nahezu der von 1024 × 768 bei 29,97 fps. Meine Ergebnisse sollten daher einen recht guten Anhaltspunkt für die Datenraten liefern, die Sie für Ihr Filmmaterial erwarten können.

Automatische Auflistung der verfügbaren Optionen

Mit dem folgenden POSIX-Befehl¹ erhalten Sie eine Liste, die größtenteils mit dem übereinstimmt, was wir unten diskutieren:

$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'

Möglicherweise möchten Sie diesen Befehl auf Ihrem eigenen Computer ausführen, um zu sehen, welche Unterstützung Ihr Build von FFmpeg bietet. FFmpeg wird selten mit jedem möglichen aktivierten Encoder erstellt.

Besprechen wir nun diese Optionen.

Völlig unkomprimiert

Wenn Ihre Definition von „unkomprimiert“ ist die Form , das Video in richtig ist , bevor es an Photonen , die von einem digitalen Display eingeschaltet ist, ist die nächste ich in der siehe ffmpeg -codecsListe bin -c:v r210, r10k, v410, v308, ayuvund v408. Dies alles ist im Wesentlichen dasselbe und unterscheidet sich nur in der Farbtiefe , im Farbraum und in der Alphakanalunterstützung .

• R210 und R10K sind 4: 4: 4 RGB mit 10 Bit pro Komponente (bpc), sodass beide ungefähr benötigen in meinem Test 708 Mbit / s für 720p. (Das sind ungefähr ⅓ TB pro Stunde, Freunde!)

  Diese Codecs packen beide 3 × 10-Bit-Farbkomponenten pro Pixel in einen 32-Bit-Wert, um die Manipulation durch Computer zu vereinfachen, die Potenz-2-Größen mögen. Der einzige Unterschied zwischen diesen Codecs besteht darin, an welchem ​​Ende des 32-Bit-Wortes die beiden nicht verwendeten Bits liegen. Dieser geringfügige Unterschied ist zweifelsohne darauf zurückzuführen, dass sie von Konkurrenzunternehmen wie Blackmagic Design und AJA Video Systems stammen .

  Obwohl dies triviale Codecs sind, müssen Sie wahrscheinlich die Blackmagic- und / oder AJA-Codecs herunterladen, um Dateien abzuspielen, die diese auf Ihrem Computer verwenden. Beide Unternehmen lassen Sie ihre Codecs herunterladen, ohne zuvor ihre Hardware gekauft zu haben, da sie wissen, dass Sie es möglicherweise mit Dateien zu tun haben, die von Kunden erstellt wurden, die über einen Teil ihrer Hardware verfügen.

• V410 ist im Wesentlichen nur die YUV-Version von R210 / R10K; Ihre Datenraten sind identisch. Dieser Codec kann trotzdem schneller codieren, weilffmpeg mit größerer Wahrscheinlichkeit ein beschleunigter Farbraumkonvertierungspfad zwischen dem Farbraum Ihrer Eingaberahmen und diesem Farbraum besteht.

  Ich kann diesen Codec jedoch nicht empfehlen, da ich die resultierende Datei nicht in einer von mir getesteten Software abspielen konnte, selbst wenn die Codecs AJA und Blackmagic installiert waren.

• V308 ist die 8-Bit-Variante von V410,in meinen Tests sindes also 518 Mbit / s . Wie bei V410 war es mir nicht möglich, diese Dateien in einer normalen Video-Player-Software wiederzugeben.

• AYUV und V408 sind im Wesentlichen dasselbe wie V308, mit der Ausnahme, dass sie einen Alpha-Kanal enthalten, unabhängig davon, ob dieser benötigt wird oder nicht! Wenn in Ihrem Video keine Transparenz verwendet wird, bedeutet dies, dass Sie die Größenstrafe der oben genannten 10-Bit-R210 / R10K-Codecs zahlen, ohne den Vorteil des tieferen Farbraums zu nutzen.

  AYUV hat eine Tugend: Es ist ein "nativer" Codec in Windows Media, daher ist zum Abspielen keine spezielle Software erforderlich.

  V408 sollte auf die gleiche Weise in QuickTime integriert sein, aber die V408-Datei kann auf meinem Mac weder in QuickTime 7 noch in 10 abgespielt werden.

Also, füge all das zusammen, wenn deine PNGs benannt sind frame0001.pngund so weiter:

$ ffmpeg -i frame%04d.png -c:v r10k output.mov
  ...or...                -c:v r210 output.mov
  ...or...                -c:v v410 output.mov
  ...or...                -c:v v408 output.mov
  ...or...                -c:v v308 output.mov
  ...or...                -c:v ayuv output.avi

Beachten Sie, dass ich im Fall von AYUV AVI angegeben habe, da es sich so ziemlich nur um einen Windows-Codec handelt. Die anderen funktionieren möglicherweise in QuickTime oder AVI, je nachdem, welche Codecs auf Ihrem Computer installiert sind. Wenn ein Containerformat nicht funktioniert, versuchen Sie es mit dem anderen.

Bei den obigen und auch den folgenden Befehlen wird davon ausgegangen, dass Ihre Eingabebilder bereits die Größe haben, die Sie für Ihr Ausgabevideo wünschen. Wenn nicht, fügen Sie etwas wie-s 1280x720 dem Befehl vor dem Namen der Ausgabedatei hinzu.

Komprimiertes RGB, aber auch verlustfrei

Wenn man , wie ich vermute, Sie tatsächlich mean „lossless“ anstelle von „unkomprimiert“ , eine viel bessere Wahl als eine der oben genannten ist Apple Quicktime - Animation über-c:v qtrle

Ich weiß, dass Sie gesagt haben, Sie wollten ein AVI, aber Tatsache ist, dass Sie wahrscheinlich einen Codec auf einem Windows-Computer installieren müssen, um eines der hier erwähnten AVI-basierten Dateiformate zu lesen, während mit QuickTime das Video eine Chance hat Eine App Ihrer Wahl kann bereits eine QuickTime-Animationsdatei öffnen. (Der obige AYUV-Codec ist die einzige mir bekannte Ausnahme, aber die Datenrate ist schrecklich hoch, nur um die Vorteile von AVI zu nutzen.)

ffmpegwird qtrlein einen AVI-Container für Sie stopfen , aber das Ergebnis ist möglicherweise nicht sehr kompatibel. In meinen Tests wird QuickTime Player ein bisschen über eine solche Datei grübeln, aber sie wird dann abgespielt. Seltsamerweise spielt VLC es nicht ab, obwohl es teilweise darauf basiert ffmpeg. Ich würde mich für diesen Codec an QT-Container halten.

Der QuickTime-Animationscodec verwendet ein einfaches RLE- Schema. Für einfache Animationen sollte es also genauso gut funktionieren wie für Huffyuv weiter unten. Je mehr Farben in jedem Frame vorhanden sind, desto mehr nähert sich die Bitrate der oben genannten vollständig unkomprimierten Optionen an. Bei meinen Tests mit Big Buck Bunny konnte ich ffmpegmir eine 165 Mbit / s- Datei im RGB 4: 4: 4-Modus über geben-pix_fmt rgb24 .

Obwohl dieses Format komprimiert ist, erhalten Ihre PNG-Eingabedateien identische Ausgabepixelwerte, aus demselben Grund wie die verlustfreie PNG-Komprimierung keine Auswirkungen auf die Pixelwerte hat.

Die ffmpegQuickTime Animation-Implementierung unterstützt außerdem -pix_fmt argb4: 4: 4: 4 RGB, dh sie verfügt über einen Alphakanal. In einer sehr groben Art ist es das QuickTime-Äquivalent zu -c:v ayuv, wie oben erwähnt. Aufgrund der verlustfreien Komprimierung sind es jedoch nur 214 Mbit / s , weniger als ⅓ der Datenrate von AYUV ohne Qualitäts- oder Funktionsverlust.

Es gibt Varianten von QuickTime Animation mit weniger als 24 Bit pro Pixel, aber sie werden am besten für immer einfachere Animationsstile verwendet. ffmpegscheint nur eines der anderen in der Spezifikation definierten Formate zu unterstützen -pix_fmt rgb555be, dh 15 bpp Big-Endian-RGB. Es ist für einige Videos tolerierbar und für die meisten Screencast-Captures und einfachen Animationen in Ordnung. Wenn Sie die Dezimierung des Farbraums akzeptieren können, finden Sie möglicherweise 122 Mbit / s Datenrate von ansprechend.

Alles zusammen:

$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24    output.mov
  ...or...                           -pix_fmt argb     output.mov
  ...or...                           -pix_fmt rgb555be output.mov

Effektiv verlustfrei: Der YUV-Trick

Nun zur Sache mit RGB und 4: 4: 4 YUV sich diese Kodierungen zwar sehr einfach von Computern verarbeiten, jedoch ignorieren sie die Tatsache des menschlichen Sehens, dass unsere Augen empfindlicher für Schwarzweißunterschiede sind als für Farbunterschiede .

Videospeicher- und -liefersysteme verwenden daher fast immer weniger Bits pro Pixel für Farbinformationen als für Luminanzinformationen. Dies wird als Chroma-Subsampling bezeichnet . Die gängigsten Schemata sind 4: 2: 0 und 4: 2: 2.

Die Datenrate von 4: 2: 0 YUV ist nur 50% höher als bei unkomprimiertem Schwarzweißvideo (nur Y) und ½ der Datenrate von 4: 4: 4 RGB oder YUV.

4: 2: 2 ist eine Art Halbwert zwischen 4: 2: 0 und 4: 4: 4. Dies ist die doppelte Datenrate von Nur-Y-Videos und ⅔ die Datenrate von 4: 4: 4.

Sie sehen auch manchmal 4: 1: 1, wie im alten DV-Kamerastandard . 4: 1: 1 hat die gleiche unkomprimierte Datenrate wie 4: 2: 0, aber die Farbinformationen sind unterschiedlich angeordnet.

Wenn Sie mit einer 4: 2: 0-H.264-Datei beginnen und diese in unkomprimiertes 4: 4: 4-RGB umcodieren, erhalten Sie absolut nichts über verlustfrei komprimiertem 4: 2: 0-YUV. Dies gilt auch dann, wenn Sie wissen, dass Ihr Workflow ansonsten 4: 4: 4 RGB ist, da es sich um eine einfache Konvertierung handelt. Video-Hardware und Software führen solche Konvertierungen routinemäßig im laufenden Betrieb durch.

Sie benötigen wirklich nur 4: 4: 4, wenn Sie Pixel-Peeping durchführen oder Farbänderungen auf Pixelebene im Video vornehmen, und Sie müssen die genauen Pixelwerte beibehalten. Die Arbeit mit visuellen Effekten (VFX) ist beispielsweise mit einem 4: 4: 4-Pixelformat einfacher, sodass High-End-VFX-Häuser häufig bereit sind, die erforderlichen höheren Datenraten zu tolerieren.

Effektiv verlustfrei: Codec-Auswahl

Sobald Sie sich mit der Farbdezimation für YUV-Codecs öffnen, eröffnen sich auch Ihre Möglichkeiten. ffmpeghat viele effektiv verlustfreie Codecs.

Huffyuv

Die am weitesten kompatible Option ist Huffyuv . Sie erhalten dies über -c:v huffyuv.

Der ursprüngliche Windows Huffyuv-Codec unterstützt nur zwei Pixelformate: RGB24 und YUV 4: 2: 2. (Tatsächlich werden zwei Arten von YUV 4: 2: 2 unterstützt, die sich nur in der Reihenfolge der Bytes auf der Festplatte unterscheiden.)

Ältere Versionen des FFmpeg-Huffyuv-Codecs unterstützen RGB24 nicht. Wenn Sie es also versuchen und FFmpeg Ihnen mitteilt, dass das yuv422pPixelformat verwendet wird, müssen Sie ein Upgrade durchführen.

FFmpeg hat auch einen Huffyuv-Codec namens FFVHuff, der YUV 4: 2: 0 unterstützt. Diese Variante ist nicht mit dem Windows DirectShow Huffyuv-Codec kompatibel, sollte jedoch in jeder darauf basierenden Software libavcodecwie VLC geöffnet werden .

• RGB24 - RGB 4: 4: 4 entspricht im Wesentlichen der RGB24-Farbraumoption von QuickTime Animation. Die beiden Codecs unterscheiden sich in der Komprimierung für eine bestimmte Datei geringfügig, sind jedoch normalerweise nahe beieinander.

  Es ist auch im Wesentlichen dasselbe wie der YUV 4: 4: 4-Modus, der von der obigen V308-Option verwendet wird. Der Farbraumunterschied macht keinen praktischen Unterschied, da die Farbraumkonvertierung in Echtzeit einfach durchzuführen ist.

  Aufgrund der verlustfreien Komprimierung von Huffyuv konnte ich ein Testvideo erstellen, das im RGB24-Modus auf ca. 251 Mbit / s komprimiert wurde, mit der gleichen visuellen Qualität, die Sie von V308 oder AYUV erhalten würden. Wenn AVI ein absolutes Muss für Sie ist, ist die Installation des Huffyuv-Codecs wahrscheinlich schmerzfreier als die Zahlung der 3-fachen Datenratenkosten von AYUV.

• YUV 4: 2: 2 - Dieser Modus ist für Video weitaus praktischer als RGB24, was zweifellos der Grund ist, warum die ffmpegEntwickler ihn zuerst implementiert haben. Wie Sie es von der oben diskutierten theoretischen Reduzierung erwarten würden, wurde meine Testdatei mit 173 Mbit / s codiert . Das ist ziemlich genau ⅔, wenn Sie die Tatsache berücksichtigen, dass die Audiospur zwischen diesen beiden Tests unverändert war.

• YUV 4: 2: 0 - Diese Option dezimiert die Farbinformationen um mehr als 4: 2: 2 und senkt die Datenrate in meinen Tests auf 133 Mbit / s .

Alles zusammen:

$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24   output.avi
  ...or...                             -pix_fmt yuv422p output.avi
  ...or...                -c:v ffvhuff -pix_fmt yuv420p output.avi

Obwohl der ffvhuffCodec beim Schreiben standardmäßig 4: 2: 0 ist und tatsächlich nur das Pixelformat in der von mir verwendeten Release-Version unterstützt, ändert sich dies. Daher sollten Sie das Flag einschließen, falls sich diese Standardeinstellung ändert.

Ut Video

Eine neuere Option im gleichen Sinne wie Huffyuv und FFVHuff ist Ut Video . Wie Huffyuv gibt es einen Windows-Videocodec, dh, jedes Windows-Programm, das einen Film abspielen kann, kann Videos mit diesem Codec abspielen, wenn der Codec installiert ist. Anders als bei Huffyuv gibt es auch einen Mac-Video-Codec, sodass Sie nicht auf FFmpeg-basierte Software oder libavcodecdas Lesen dieser Dateien auf Macs beschränkt sind.

Dieser Codec ist in Bezug auf Farbräume sehr flexibel, daher möchte ich nur einige Beispiele für gängige Farbräume nennen:

• 4: 4: 4 RGB via -f avi -c:v utvideo -pix_fmt rgb24liefert eine Ausgabe von 178 Mbit / s

• 4: 4: 4 YUV via -f avi -c:v utvideo -pix_fmt yuv444pliefert eine Ausgabe von 153 Mbit / s

• 4: 2: 2 YUV via -f avi -c:v utvideo -pix_fmt yuv422pliefert eine Ausgabe von 123 Mbit / s

• 4: 2: 0 YUV über -f avi -c:v utvideo -pix_fmt yuv420pgibt 100 Mbit / s aus

Ich vermute, dass 4: 4: 4 YUV in diesem Test besser als 4: 4: 4 RGB ist, obwohl diese beiden technisch gleichwertig sind, da das Quellvideo 4: 2: 0 YUV ist. Die Anordnung der Daten im YUV-Format ermöglicht also eine bessere verlustfreie Komprimierung durch Gruppieren der teilweise redundanten U- und V-Kanäle in der Datei.

FFV1

Eine weitere interessante Option in diesem Bereich ist FFmpegs eigener FFV1Codec . Dies wird hauptsächlich als Archivierungs-Codec und nicht als Wiedergabe- oder Bearbeitungs-Codec verwendet. Da jedoch so viel Software entweder auf der libavcodecBibliothek basiert, auf der FFmpeg basiert, oder libavcodecüber Tools wie z. B. verwendet werden kann ffdshow, kann dies für Sie trotzdem nützlich sein.

Standardmäßig ffmpegwird der Farbraum Ihrer Eingabedateien beibehalten, wenn Sie einen flexiblen Codec wie FFV1 verwenden. Wenn Sie also eine der offiziellen Big Buck Bunny MP4-Dateien mit 4: 2: 0 YUV einspeisen, erhalten Sie diese aus, es sei denn, Sie geben eine -pix_fmtFlagge an ffmpeg. Dies führt zu einer Ausgabedatei mit 63 Mbit / s .

Wenn Sie FFV1 zwingen, einen 4: 4: 4-YUV-Farbraum mit zu verwenden -pix_fmt yuv444p, steigt die Dateigröße nur auf 86 Mbit / s , was uns in diesem Fall jedoch nichts kostet, da wir von einem 4: 2: 0-Original codieren . Wenn Sie jedoch stattdessen wie in der ursprünglichen Frage eine Reihe von PNGs eingeben, wird in der Ausgabedatei wahrscheinlich der Farbraum bgraoder bgr0verwendet, bei dem es sich lediglich um Neuanordnungen des oben genannten Farbraums argbund des rgb24Farbraums handelt.

Verlustfreies H.264

Eine weitere interessante Alternative ist Lossless H.264 . Dies ist so ziemlich eine reine x264- Sache, aber diejenigen, die FFmpeg auf der Codierungsseite verwenden, verwenden wahrscheinlich auch andere Software, die auch libx264auf der Decodierungsseite enthalten ist, wie beispielsweise VLC.

Der einfachste Weg, um eine solche Datei zu erhalten, ist:

$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4

Das -qp 0Flag ist der Schlüssel: Höhere Werte führen zu einer verlustbehafteten Komprimierung. (Sie können auch geben -crf 0, um den gleichen Effekt zu erzielen.)

Wie bei FFV1 ffmpegwird versucht, den besten Ausgabefarbraum im Hinblick auf den Eingabefarbraum zu erraten. Zum Vergleich mit den obigen Ergebnissen habe ich mehrere Codierungsdurchläufe für die Big Buck Bunny-Quelldatei mit verschiedenen Farbräumen ausgeführt:

• yuv444p : Dies ist die Auswahl,ffmpeg wenn Sie wie in der ursprünglichen Frage einen RGB-PNG-Stream angeben und eine 44-Mbit / s- Datei mit unserer Testdatei erstellen

• yuv422p : Dies ist ähnlich wie der Standardfarbraum für Huffyuv, aber wir erhalten in diesem Fall eine 34-Mbit / s- Datei, eine ziemliche Ersparnis!

• yuv420p : Dies ist die Standardeinstellung für die offiziellen MP4s von Big Buck Bunny, mit denen ich teste, und führt zu einer 29-Mbit / s- Datei.

Beachten Sie, dass Sie eine Menge Kompatibilität handeln, um so kleine Dateigrößen zu erhalten. Deshalb habe ich nicht einmal versucht, dies in einen AVI- oder MOV-Container zu packen. Es ist so eng mit x264 verbunden, dass Sie stattdessen auch den Standardcontainertyp (MP4) verwenden können. Sie könnten dafür auch so etwas wie Matroska verwenden .

Sie können einen Teil dieser Bitrate für eine schnellere Codierungszeit austauschen, indem Sie sie hinzufügen -preset ultrafast. Dadurch wurde die Bitrate meiner Testdatei im YUV 4: 2: 2-Modus auf 44 Mbit / s erhöht , aber wie versprochen viel schneller codiert. Die Dokumente behaupten, dass -preset veryslowsich das auch lohnt, aber es hat zu einer viel längeren Codierungszeit geführt und dabei nur ein kleines bisschen Platz gespart. Ich kann es nicht empfehlen.

Andere

ffmpegunterstützt auch den Nur-Dekodierungsmodus für Lagarith und den Nur-Kodierungsmodus für verlustfreies JPEG . Diese beiden Codecs sind sich eigentlich ziemlich ähnlich und sollten Dateien mit der gleichen Qualität etwas kleiner als Huffyuv machen. Wenn die ffmpegEntwickler jemals Lagarith-Codierung hinzufügen, wäre dies eine starke Alternative zu Huffyuv. Ich kann Lossless JPEG jedoch nicht empfehlen, da es keine umfassende Dekodierungsunterstützung bietet.

Wahrnehmungsbedingt verlustfrei: Oder Sie können wahrscheinlich mit einigem Verlust davonkommen

Dann gibt es die Codecs, die wahrnehmungsbedingt verlustfrei sind. Wenn Sie kein Pixel-Peeping durchführen, können Sie mit ziemlicher Sicherheit nicht feststellen, dass dies andere visuelle Ergebnisse liefert als die beiden vorherigen Gruppen. Wenn Sie auf die Idee eines absoluten Nullwechsels zwischen dem Videoerfassungssensor und dem Anzeigegerät verzichten, können Sie erhebliche Einsparungen erzielen:

• Apple ProRes :-c:v proresoder-c:v prores_ks- ProRes ist ein profilbasierter Codec. Dies bedeutet, dass es mehrere Varianten gibt, bei denen sich Qualität und Platzbedarf unterscheiden:

  • ProRes 4444 codiert unser Testvideo mit nur 114 Mbit / s und bietet dennoch VFX-Qualität . Es gibt derzeit drei verschiedeneprores*Codecs in FFmpeg,prores_ksunterstütztaber nurProRes 4444, wie ich dies schreibe, über die-profile:v 4444Option.

    Wenn Sie sich fragen, warum Sie sich mit ProRes 4444 über verlustfreies H.264 hinwegsetzen sollten, sind Kompatibilität, Dekodierungsgeschwindigkeit, Vorhersagbarkeit und der Alpha-Kanal ausschlaggebend.

  • ProRes 422 spart noch mehr Platz und benötigt nur 84 Mbit / s , um ein Ergebnis zu erzielen, das Sie nur durch Pixel-Peeping von ProRes 4444 unterscheiden können. Sofern Sie nicht den von ProRes 4444 angebotenen Alpha-Kanal benötigen, gibt es wahrscheinlich keinen Grund, auf ProRes 4444 zu bestehen.

    ProRes 422 ist ein engerer Konkurrent zur oben genannten verlustfreien H.264-Option, da keine einen Alpha-Kanal unterstützt. Sie sollten die höhere Bitrate von ProRes tolerieren, wenn Sie Kompatibilität mit Apple Pro-Video-Apps, einen geringeren CPU-Overhead für das Codieren und Decodieren oder vorhersehbare Bitraten benötigen. Letzteres ist beispielsweise bei Hardware-Encodern wichtig. Wenn Sie dagegen mit den Kompatibilitätsproblemen von Lossless H.264 fertig werden, haben Sie die Möglichkeit, den 4: 2: 0-Farbraum zu verwenden, der in keinem ProRes-Profil verfügbar ist.

    Alle drei ProRes-Encoder in FFmpeg unterstützen das ProRes 422-Profil. Daher ist die einfachste Option -c:v prores, die richtige Vorgehensweise zu wählen , anstatt -c:v prores_ks -profile hqvon der Funktion zur automatischen Profilerstellung abhängig zu prores_kssein.

  Es gibt noch sparsamere ProRes-Profile, die jedoch entweder für SD-Videos oder als Proxy für Dateien mit voller Auflösung gedacht sind .

  Das Hauptproblem von ProRes ist, dass es außerhalb der Apple- und Pro-Videowelten noch keine breite Unterstützung bietet.

• Avids DNxHD ist ein ähnlicher Codec wie ProRes, ist jedoch nicht an die Apple Pro-Videowelt gebunden. Avid bietet frei herunterladbare Codecs für Windows und Macintosh, und FFmpeg unterstützt diese jetzt über-c:v dnxhd.

  Da DNxHD ein profilbasierter Codec wie ProRes ist, wählen Sie das Profil aus dem vordefinierten Satz aus und geben dem Codec an, welche Bildgröße, Bildrate und Bitrate verwendet werden soll. Für die Big Buck Bunny-Testdatei ist das -b:v 60MProfil am besten geeignet. Es überrascht nicht, dass die resultierende Datei ungefähr 59 Mbit / s beträgt .

• Verlustarmes MJPEG :-vcodec mjpeg -qscale:v 1- Dies ist weitaus häufiger als verlustfreies JPEG. Tatsächlich war dies einst ein recht verbreiteter Codec für die Videobearbeitung und wird immer noch häufig von Netzwerk-Streaming-Videokameras verwendet. All diese Geschichte bedeutet, dass es einfach ist, Software zu finden, die dies unterstützt.

  Erwarten Sie von diesem Codec eine ziemlich große Variabilität der Datenraten. Ein Test, den ich gerade hier gemacht habe, ergab 25 Mbit / s für 720p-Video. Die Komprimierung ist hoch genug, um mich wegen des Verlusts nervös zu machen, aber für mich sah es ziemlich gut aus. Allein aufgrund der Datenrate würde ich sagen, dass dies in Bezug auf die Qualität wahrscheinlich bei 12 Mbit / s MPEG-2 oder 6 Mbit / s H.264 liegt.

Alles zusammen:

$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
  ...or...                -c:v prores_ks -profile:v hq   output.mov
  ...or...                -c:v prores                    output.mov
  ...or...                -c:v dnxhd -b:v 60M            output.mov
  ...or...                -c:v mjpeg -qscale:v 1         output.avi

Fazit dieser Methoden ist, dass "gut genug" wirklich gut genug ist, es sei denn, Sie tun etwas sehr Anspruchsvolles.

Fußnoten und Exkursionen

1. Der Befehl sollte unter Linux, macOS, den BSDs und Unix funktionieren. Unter Windows können Sie über Cygwin oder WSL eine POSIX-Befehlszeile abrufen .

2. Es gibt mehrere Gründe, warum die von diesem Befehl erstellte Liste nicht perfekt zu den Codecs passt, die ich oben besprochen habe:

   • Die zweite grepsoll ungeeignete Codierer herausfiltern, bmpdie keine "Video" -Codecs sind, obwohl sie Vin dieser Liste markiert sind . Technisch gesehen könnten Sie wahrscheinlich viele davon in einen Container wie AVI, MP4 oder MKV packen, um ein Video mit einer einzelnen Datei zu erhalten. Diese Datei kann jedoch wahrscheinlich nur von einem auf ffmpegoder basierenden Programm gelesen werden libavcodec.

     Hiervon gibt es einige Ausnahmen, wie z. B. -f avi -c:v ljpeg"Lossless MJPEG", aber in der Regel sind wir nicht daran interessiert, viele Standbilddateien in einen A / V-Container zu packen, um hier einen Film zu erstellen. Wir wollen hier allgemein anerkannte Videocodecs, keine semantischen Tricks.

   • Der Befehl kann derzeit einige ungeeignete Encoder wie GIF nicht herausfiltern, da sie derzeit in den ffmpeg -codecsAusgabe- bitmapoder imageDateiformaten nicht beschrieben sind .

     GIF ist ein interessanter Fall: Es unterstützt mehrere Bilder in einer einzelnen GIF-Datei mit Timing-Informationen für die Bewegungswiedergabe, ist jedoch aus verschiedenen Gründen für unsere Diskussion hier völlig ungeeignet.

   • Einige der Optionen , die gezeigt werden , sind veraltet oder nie wirklich viel Traktion, wie bekam flashsv, diracund snowso ist es nicht wert ist , sie oben diskutiert.

   • Einige der Optionen in dieser Liste sind nur für die Verwendung in Pipelines zwischen ffmpegInstanzen oder zwischen ffmpegund einem anderen Programm vorgesehen, z. B. rawvideound wrapped_avframe, und sind daher für unsere Zwecke hier nicht geeignet.

   • Gegen Ende der obigen Diskussion erweitere ich den Umfang der Frage mit Bedacht um einige sorgfältig ausgewählte verlustbehaftete Optionen, damit sie den ersten grepFilter im obigen Befehl nicht bestehen.

Also habe ich meine eigene Antwort zu lange gemacht.
TL; DR-Zusammenfassung: Zum verlustfreien Speichern einer Bildsequenz verwenden Sie libx264oder libx264rgbmit -preset ultrafast -qp 0. Es ist fast so schnell wie ffvhuff, mit viel geringerer Bitrate und dekodiert schneller. huffyuvwird außerhalb von ffmpeg viel häufiger unterstützt, unterstützt jedoch nicht so viele Pixelformate wie ffvhuff. Dies ist ein weiterer Grund für die Verwendung von h.264, vorausgesetzt, Ihre anderen Tools können das h.264- High 4:4:4 PredictiveProfil verarbeiten, das x264 im verlustfreien Modus verwendet. x264 kann nur intern verwendet werden, wenn ein schneller wahlfreier Zugriff auf beliebige Frames erforderlich ist.

Achten Sie auf einen ffmpeg-Fehler, der sich auf libx264rgb auswirkt, wenn Sie aus einem Verzeichnis mit Bildern lesen. (Und wer weiß, in welchen anderen Fällen?) Testen Sie Ihr Setup vor der Verwendung auf Verlustfreiheit. (einfach mit ffmpeg -i in -pix_fmt rgb24 -f framemd5on source und verlustfrei komprimiert)

edit: utvideocodiert und decodiert ziemlich schnell und ist ein viel einfacherer Codec als h.264. Es handelt sich im Grunde genommen um ein modernes huffyuvModell mit Unterstützung für nützlichere Farbräume. Wenn Sie jemals ein Problem mit h.264 haben, versuchen Sie als nächstes utvideo für temporäre Dateien.

edit2: PNG als RGB-Codec scheint sich zumindest auf dem Sintel-Trailer gut zu machen.

Siehe auch meine ähnliche Antwort auf eine ähnliche Frage: https://superuser.com/a/860335/20798

Die Antwort von Warren Young enthält viele Informationen zu verschiedenen Rohformaten und Codecs. Ich denke, die Antwort wäre nützlicher, wenn sie kürzer wäre, also gebe ich eine neue Antwort. Wenn Sie mit Software arbeiten, die verlustfreies x264 oder ffvhuff nicht unterstützt, sind einige dieser Informationen wahrscheinlich immer noch nützlich.

Die nützlichste Definition von "verlustfrei" in diesem Zusammenhang ist, dass Sie die Eingabe Bit für Bit wiederherstellen können. Machen Sie sich keine Sorgen über Qualitätsverluste durch Videokodierung, unabhängig davon, was Sie tun.

http://en.wikipedia.org/wiki/Chroma_subsampling

Vermeiden Sie im Idealfall mehrere Farbraumkonvertierungen. Die Rundungsfehler können sich möglicherweise aufbauen. Wenn Sie Ihr Video mit Filtern bearbeiten möchten, die im RGB-Farbraum funktionieren, ist es sinnvoll, diesen RGB-Wert beizubehalten, sofern die höheren Bitraten kein Problem darstellen. Sie werden wahrscheinlich letztendlich ein yuv 4:2:0Video produzieren, aber abhängig von den Filtern, die Sie anwenden werden, ist es möglicherweise nützlich, die zusätzliche Chroma-Auflösung beizubehalten.

So oder so, lossless x264 und ffvhuff sowohl Unterstützung RGB und YUV 4:4:4, 4:2:2und 4:2:0. Ich würde x264 vorschlagen, da es schnell zu dekodieren ist. Wenn Sie versuchen, RGB HD-Videos in Echtzeit wiederzugeben, versuchen Sie opengl anstelle von xv, da xv auf meinem System nur yuv-Eingaben akzeptiert. mplayer brauchte zusätzliche CPU-Zeit, um eine Farbraumkonvertierung durchzuführen.

Quelle für die folgenden Encodertests: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Sie haben vergessen, die y4m-Dateien für den Sintel-Trailer zu gzipen, daher ist der Png-Tarball tatsächlich viel kleiner.

ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \
-c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \
frompng.sintel.264rgb.mkv

z.B

peter@tesla:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv
ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers
  built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000
  libavutil      54. 16.100 / 54. 16.100
  libavcodec     56. 20.100 / 56. 20.100
  libavformat    56. 18.100 / 56. 18.100
  libavdevice    56.  3.100 / 56.  3.100
  libavfilter     5.  7.100 /  5.  7.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, image2, from '1080/sintel_trailer_2k_%4d.png':
  Duration: 00:00:50.12, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
Input #1, flac, from 'sintel_trailer-audio.flac':
  Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s
    Stream #1:0: Audio: flac, 48000 Hz, stereo, s16
File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x2770760] using SAR=1/1
[libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'frompng.sintel.264rgb.mkv':
  Metadata:
    encoder         : Lavf56.18.100
    Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.20.100 libx264rgb
    Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit)
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb))
  Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 1253 fps= 18 q=-1.0 Lsize=  834790kB time=00:00:51.96 bitrate=131592.5kbits/s
video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025%
[libx264rgb @ 0x2770760] frame I:6     Avg QP: 0.00  size:612470
[libx264rgb @ 0x2770760] frame P:1247  Avg QP: 0.00  size:678787
[libx264rgb @ 0x2770760] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264rgb @ 0x2770760] mb P  I16..4: 50.3%  0.0%  0.0%  P16..4: 12.0%  0.0%  0.0%  0.0%  0.0%    skip:37.6%
[libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2%
[libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48%  1%  1%
[libx264rgb @ 0x2770760] kb/s:135693.94

Beachten Sie, dass ich vergessen habe, anzugeben -r 24 fps , damit av nicht mit dem Audio synchron bleibt. (und die Bitrate (aber nicht die Dateigröße) ist ebenfalls deaktiviert. Der Standardwert für ffmpeg ist 25fps.) Die CPU in diesem Computer ist ein Core2duo 2.4GHz (E6600) der ersten Generation (conroe).

Ergebnisse:

4.5M    sintel_trailer-audio.flac  # this is muxed in to every mkv
948M    1080  # the directory of PNGs
940M    /var/tmp/dl/sintel_trailer-1080-png.tar.gz
7434M   sintel.y4m  # yuv444, uncompressed.  mplayer gets the colors wrong?
2342M   qtrle.mkv   # encode went at 16fps, so qtrle is slower and worse filesize
2105M   sintel.huff.mkv  # ffvhuff with default options, rgb pix fmt
1228M    sintel.utvideo.mkv  # muxed without audio, I should update the others this way
946M    png-copy.mkv  # -codec copy makes a MPNG stream.  Use -codec png for non-png sources, but it won't make PNGs as small.  Decodes very fast
824M    lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate.
816M    frompng.sintel.264rgb.mkv
735M    sintel.x264rgb.medium.nocabac.mkv  # encode went at 3.3 fps instead of 18.  Better gain than for live-action, though
626M    sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps.  With CABAC, 16 ref frames, etc. etc.
512M    lossy.prores.mov # yuv422p10le, 12fps
341M    sintel.yuv420.x264.lossless.mkv
21M     lossy.rgb.crf26.preset=medium.mkv
13M     lossy.yuv420.crf26.preset=medium.mkv  # remember this is WITH 4.5MB audio

Beachten Sie, dass mediainfo nicht über RGB h.264 Bescheid wissen und dass es sich bei den Dateien immer noch um YUV handelt.

Überprüfen Sie, ob es wirklich verlustfrei war:

ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5
ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24  -f framemd5 x264rgb.framemd5
diff -s *.framemd5
Files png.framemd5 and x264rgb.framemd5 are identical

Auf diese Weise können Sie die ursprüngliche PNG-Eingabe wiederherstellen, dh Sie können PNGs mit identischen Bilddaten erstellen.

Beachten Sie die -pix_fmt rgb24für den x264-Test. Der h.264-Decoder von ffmpeg gibt eine gbrp-Ausgabe (planar, nicht gepackt) aus, sodass die Bits identisch sind, jedoch in einer anderen Reihenfolge. Der "Container" von framemd5 unterwirft keinerlei Formatbeschränkungen, aber Sie erhalten nur dann das gleiche md5, wenn die Bits gleich angeordnet sind. Ich habe mir gerade angesehen, was ffmpeg für eine pix fmt verwendet, als ich es mit PNGs fütterte, und das dann als Argument verwendet-pix_fmt für die Dekodierung verwendet habe. Dies ist übrigens der Grund, warum vlc keine RGB h.264-Dateien wiedergibt (bis zur nächsten Veröffentlichung oder bei aktuellen nächtlichen Builds): Das gbrp-Pixelformat wird nicht unterstützt.

Für yuv Gebrauch libx264nicht libx264rgb. Sie müssen keine RGB-Version von x264 installieren, die eigentliche Bibliothek unterstützt beides. Es ist nur ffmpeg, das es als zwei unterschiedlich benannte Encoder implementiert hat. Ich denke, wenn sie das nicht getan hätten, wäre das Standardverhalten, die rgb-Eingabe als rgb zu belassen und sehr langsam zu laufen, während sie eine viel höhere Bitrate für die gleiche Qualität produzieren. (du musst noch manchmal verwenden, -pix_fmt yuv420pwenn du 420statt 444h.264 ausgabe willst.

Sofern Sie keine Dateien für die Langzeitspeicherung erstellen, sollten Sie immer -preset ultrafastverlustfreies x264 verwenden. Mehr Referenzbilder und Bewegungssuche machen kaum einen Unterschied für verlustfreies, für nicht animiertes Material mit jeglichem Rauschen. CABAC benötigt eine große Menge an CPU bei verlustfreien Bitraten, sogar zum Dekodieren. Nur für Archivierungszwecke verwenden, keine Scratch-Dateien. (Ultraschnell deaktiviert CABAC). CABAC spart 10 bis 15% Bitrate.

Wenn Sie möchten, dass jeder Frame ein Keyframe ist, legen Sie fest -keyint 1. Dann wird Sie die Videobearbeitungssoftware nicht einschränken, die nur Keyframes bearbeiten oder schneiden möchte.

So beantworten Sie die ursprüngliche Frage: Gehen Sie wie folgt vor, um temporäre Dateien zu durchsuchen, während Sie schrittweise vorgehen (z. B. ein langsames Deinterlace, das verlustfreie Ausgabe speichert, bevor Sie andere Vorgänge ausführen):

ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv

Wenn Sie wirklich eine Ausgabe in Bilddateien benötigen, die Sie mit Standbild-Tools bearbeiten können, dekodieren Sie diese unbedingt in png. Sie werden nicht mehr als das niedrigstwertige der 8 Bits für jeden der Y-, Cb- und Cr-Werte für jedes Pixel verlieren.

x264 kommt hier WIRKLICH gut heraus, weil es viele schwarze Rahmen mit ein bisschen Text, ein Ein- und Ausblenden und eine perfekte Ähnlichkeit zwischen großen Bereichen vieler Rahmen gibt, die es sogar ausnutzt -preset ultrafast. Bei Live-Action sehe ich immer noch x264 mit der halben Dateigröße von ffvhuff (yuv420).

Für alle Neugierigen: Die verlustfreie rgb-Kodierung mit hoher CPU-Zeit hatte (x264 core 144 r2525):

[libx264rgb @ 0x35b97a0] frame I:27    Avg QP: 0.00  size:604367
[libx264rgb @ 0x35b97a0] frame P:1226  Avg QP: 0.00  size:517512
[libx264rgb @ 0x35b97a0] mb I  I16..4..PCM: 46.3% 38.1% 15.7%  0.0%
[libx264rgb @ 0x35b97a0] mb P  I16..4..PCM: 24.3%  5.4%  4.5%  0.0%  P16..4: 10.5%  3.3%  5.7%  0.0%  0.0%    skip:46.3%
[libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1%
[libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1%
[libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64%  1%  0%
[libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13%  2%  1%  1%  1%  1%  1%
[libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37%  5%  5%  6%  5%  5%  4%  3%
[libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7%
[libx264rgb @ 0x35b97a0] ref P L0: 74.5%  4.2%  9.1%  4.1%  2.1%  1.7%  1.2%  0.8%  0.6%  0.5%  0.3%  0.2%  0.2%  0.2%  0.2%  0.1%
[libx264rgb @ 0x35b97a0] kb/s:99721.66

Beachten Sie den sehr hohen Anteil an gewichteten p-Frames und auch den sehr hohen Anteil an überspringenden Makroblöcken. Jeder Szenenübergang ist eine Überblendung, kein Schnitt, und x264 nutzt den Vorteil, wenn Sie der CPU Zeit geben, um herauszufinden, wie.

Weitere Hinweise (verlustbehaftete Codecs zum Bearbeiten):

Für das Scrubben vorwärts / rückwärts durch Clips werden in der Regel ausschließlich interne Codecs bevorzugt (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). Ich würde mir vorstellen, dass reguläre AVCs mit kurzen GOPs (1/2 bis 1 Sek.) Auch ziemlich gut scrubben würden, solange die Software wusste, was sie tat ein Zwischenbild, wenn Sie auf einer Timeline so stark vergrößert sind, dass dies erforderlich ist).

Ich habe hier und unter https://video.stackexchange.com/ einige negative Dinge über Pro-Res gepostet , z. B. "Was nützt es, wenn die Komprimierung langsamer und schlechter ist als bei einem verlustfreien Codec", aber es hat einige interessante Funktionen. Apple gibt an, dass es mit einer halben Auflösung dekodieren kann, wobei nur 1/3 der CPU-Zeit für die Dekodierung in voller Auflösung benötigt wird.

Die Implementierung von ffmpegs Prores ist wahrscheinlich auch nicht so schnell wie die von Apple, weshalb meine Tests mit ffmpeg es langsam aussehen ließen. Es lohnt sich wahrscheinlich nicht, einen kostenlosen Software-Workflow mit ffmpeg-basierten Tools zu verwenden, aber es lohnt sich möglicherweise, ihn zu testen, wenn Sie kommerzielle Software verwenden.

Ich mache nicht viel Videobearbeitung, meistens nur Codierung, daher weiß ich nicht genau, welche Tests für Codecs wie Prores geeignet sind. Ich würde vermuten, dass mjpeg vielleicht eine gute schnelle Alternative wäre, wenn Short-GOP x264 nicht gut funktioniert. Es gibt asm-beschleunigte Implementierungen von JPEG in Linux-Distributionen und es ist ein ziemlich einfacher Codec. Sie können die Qualität nach Bedarf erhöhen oder verringern, um den Kompromiss zwischen Qualität und Dateigröße sowie Kodierungs- / Dekodierungsgeschwindigkeit zu finden. Es ist uralt, aber wenn Sie einen Nur-Intra-Codec möchten, der wirklich schnell ist, schlägt er möglicherweise x264.

Für x264 würde ich so etwas versuchen x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (nur intern, ohne die anderen Einstellungen --avcintra-class). Hinweis superfast(ohne CABAC), oder faster, ultrafastist wahrscheinlich nicht am besten für den verlustbehafteten Betrieb. Ich denke, ultraschnell verliert viel an Qualität, ohne viel schneller zu sein. Je niedriger die Qualität (höhere crf), desto mehr CPU-Zeit muss aufgewendet werden, um eine bessere Kodierung zu finden. Vieles davon ist jedoch bei einer GOP-Größe von 1 wahrscheinlich nicht relevant.

Wenn Sie bei einer GOP-Größe> 1 so viele Bits in die Codierung werfen, dass eine bessere Inter-Vorhersage beim Codieren der Residuen nicht viele Bits einspart (weil Rauschen / Körnung / subtile Änderungen zwischen Frames sehr genau erhalten bleiben), dann einfach superschnell ist wohl in ordnung. Andernfalls wäre mit --keyint=30oder etwas wahrscheinlich --preset veryfast --crf 12interessant.

Theoretisch sollte die Qualität bei einer bestimmten CRF-Einstellung in allen Presets konstant sein. Wenn Sie nach kleineren Dateien suchen (schnellere Dekodierung), ist es sinnvoll, einige Qualitätsmerkmale und einige Zeit für die Kodierung abzuwägen.

Ich denke, ffmpeg unterstützt tatsächlich die Konvertierung in unkomprimiertes Video.
Ich habe ffmpeg -i input.mp4 -vcodec rawvideo out.avi verwendet und das resultierende .avi hatte ungefähr die richtige Dateigröße. Windows Media Player schien es nicht richtig abspielen zu können, aber es konnte von VirtualDub gelesen werden und ich sah keinen Verlust in der Bildqualität.