Kann H264 mit ProRes 422 "Äquivalenz" erreichen?

Nun, den Zahlen nach zu urteilen, hat h264 eine geringere Bittiefe und Farbgenauigkeit als ProRes 422. PR422 hat 10 Bit und 4:2:2 Chroma Subsampling, h264 hat 8 Bit und 4:2:0, es sei denn, Sie codieren im Hi422P Intra-Profil das in freier Wildbahn nicht sehr gut unterstützt wird, aber 10bit und 4:2:2 bietet. In diesem Fall glaube ich also nicht, dass Sie irgendeinen Unterschied zwischen den beiden Formaten haben werden, aber eine bessere Komprimierungsrate als mit ProRes.

E: Wenn du richtig Affenscheiße machen willst, kannst du auch im 4:4:4 Intra Profile codieren, das bis zu 14 Bit Farbtiefe unterstützt. Also ProRes4444 technisch überlegen. Obwohl Sie wahrscheinlich keine kommerzielle Anwendung finden werden, die dies unterstützt.

Außerdem denke ich, dass die Bereitstellung von Inhalten für das Kino weder in h264 noch in ProRes 422 erfolgen sollte, insbesondere wenn Sie vorhaben, anschließend in einen verlustfreien Codec (JPEG2000/DCP) zu codieren. Es macht einfach nicht viel Sinn, alles, was Sie verlieren, ist Qualität, obwohl es nicht nötig ist, Sie sparen nur Platz, bis Sie Ihr DCP kodieren. Es gibt andere gute verlustfreie Codecs, die eine sehr gute Komprimierung bieten, die vor der Codierung des DCP verwendet werden können.

Sie könnten zum Beispiel direkt zu DCP gehen, der Adobe Media Encoder bietet seit CC 2014 den Export nach 2k DCP an, Sie können einen Codierungsschritt überspringen und haben einen verlustfreien Codec mit sehr guter Komprimierungsrate.

Ein weiterer großartiger Zwischencodec ist UtVideo sowie Schrödinger (eine Implementierung des Dirac-Codecs von BBC, erhältlich über FFmpeg ).

Am Ende unterscheidet sich die Theorie jedoch immer von der Praxis und wenn Sie nicht für bundesweite Kinos mit hervorragenden Projektoren und was auch immer liefern, wird dieser Qualitätsunterschied in Ihrer Lieferkette vernachlässigbar sein. Das einzige, was ein Fallstrick sein könnte, ist, dass h264 sehr komplex ist und daher immer anfällig für einige seltsame visuelle Fehler ist, sodass eine Endkontrolle bei h264 immer eine Notwendigkeit ist.

Hat jemand Tests durchgeführt oder gesehen, in denen Apple ProRes 422 mit H.264 mit hoher Bitrate verglichen wurde?

Nein, aber ich kann Ihnen sagen, dass x264 so verlustfrei werden kann, wie Sie möchten (oder sogar mathematisch verlustfrei, mit -qp 0). x264 kann h.264-Streams in 4:2:0-, 4:2:2- oder 4:4:4-YUV-Farbräumen mit 8 oder 10 Bit pro Komponente erzeugen. (Es kann auch RGB, aber wenn Sie es nicht verlustfrei machen, erhalten Sie wahrscheinlich eine bessere Qualität pro Bitrate von YUV.)

Decoder-Unterstützung für etwas anderes als 4:2:0 8bit ist nicht so weit verbreitet. (z. B. Grafikkarten haben Hardware-Decoder, die nur 4:2:0 8bit beschleunigen können).

Beachten Sie, dass x264 entweder für 8- oder 10-Bit-Ausgabe kompiliert werden muss. Sie benötigen einen separaten Build von libx264 (oder einen ganz separaten statischen Build von ffmpeg) für 8-Bit und 10-Bit. Beide können mit jeder Eingabebittiefe umgehen, die Sie darauf werfen möchten, geben aber immer die Bittiefe aus, für die sie kompiliert wurde.

Das Hi444PP h.264-Profil unterstützt bis zu 14 Bit Tiefe für verlustbehafteten oder verlustfreien Betrieb, aber x264 unterstützt immer noch nur 8 oder 10 Bit. (Auch 9bit, wenn Sie es mit Bittiefe = 9 kompilieren, aber das macht wirklich keinen Sinn. Der Geschwindigkeitseinbruch kommt, sobald Sie über 8 hinausgehen.)

Übrigens, selbst wenn Ihre Eingabe 8-Bit und Ihre endgültige Anzeige 8-Bit-RGB ist, sieht 10-Bit-h.264 bei gleicher Bitrate besser aus. 8bit h.264 ist ein Kompromiss zwischen Geschwindigkeit und Qualität. (und offensichtlich Decoder-kompatibel.) Google sollte einige Threads zu doom9 und ein PDF von ateme finden, um diese Behauptung zu untermauern.

Denken Sie zum Verständnis daran, dass verlustbehaftete Codecs nicht versuchen, alle Eingabebits zu reproduzieren, sondern nur etwas, das ähnlich aussieht. 10 Bit ermöglicht eine höhere interne Präzision für die Bewegungsvorhersage und ermöglicht es dem Encoder, die niederwertigsten Bits für eine bessere CABAC-Effizienz (Trellis) zu optimieren, ohne einen sichtbaren Unterschied zu erzeugen. So erhalten Sie weniger Streifenbildung bei Farbverläufen.

Wir fragen uns, ob es möglich ist, mit H.264 eine ausreichende Qualität zu erreichen. Sagen wir, mit Bitraten von 50-100 MBit/s und dem Anpassen der GOP-Größe/-Struktur. (z. B. nur „I“-Frames verwenden.)

Das Erzwingen von mehr I-Frames oder nur I-Frames erhöht die Qualität NICHT. h.264-Encoder "wissen", wie sich ihre Ausgabe von ihrer Eingabe unterscheidet, und verwenden I-Makroblöcke, wenn sie die bessere Wahl sind.

Kurze GOPs sind nützlich für die Suche oder Fehlerbehebung in Echtzeit-Streaming-Anwendungsfällen. Bei der Videoproduktion können Sie mit einer kurzen GOP einen Bildschritt rückwärts ausführen, ohne sehr viele Bilder aus dem vorherigen Schlüsselbild decodieren zu müssen. So können Sie präziser schrubben.

Wenn das Suchen überhaupt kein Problem darstellt, können Sie keyint = 1000 festlegen, und dann könnte x264 eine GOP fast so lange verwenden, wie es wollte. (Die Szenenschnitterkennung ist in allen Voreinstellungen außer Ultrafast aktiviert, sodass x264 jedes Mal ein IDR (Schlüsselbild) verwendet, wenn ein Szenenschnitt einen I-Frame sowieso zu einer guten Idee macht.)

Update 2: Ich habe weitere Tests durchgeführt ... mit Adobe Media Encoder unter Verwendung von MPEG2 und dem Profil "4:2:2" ist die ProRes-Datei von 1.920 MB auf 290 MB gestiegen! Und ich würde sagen, subjektiv ist das zu 99% genauso gut. Das ist bemerkenswert. (Mit H264 war ich auf 500-700 MB herunter)

Wenn Sie mit MPEG2 so gute Ergebnisse erzielt haben, sollten Sie mit einem anständigen h.264-Encoder problemlos noch kleinere Dateien erhalten. Ihr Inhalt lässt sich wahrscheinlich ziemlich gut komprimieren (geringe Körnung, einige Bereiche mit großer Ähnlichkeit).

Wenn Sie Ihre Eingabe in einer Datei haben, die ffmpeg lesen kann (dh fast jedes Format),

ffmpeg -i in.mp4 -c:a copy -c:v libx264 -preset medium -tune film -crf 10 -movflags +faststart out.mp4

CRF 10 ist weit mehr als visuell verlustfrei. ffmpeg verwendet standardmäßig denselben Farbraum wie die Eingabe, wenn der Ausgabecodec dies unterstützt. Wenn Ihre Eingabe 4:4:4 ist, Sie aber Ihr Chroma unterabtasten möchten, verwenden Sie etwas wie:

ffmpeg -i in ... -sws-flags lanczos+print_info -pix_fmt yuv422p  out
...
[swscaler @ 0x33be0c0] Lanczos scaler, from rgb24 to yuv422p using MMXEXT

Update 1: Wie würde man den Unterschied technisch "testen"? Oder messen Sie die Farbinformationen?

Messen Sie die Ausgabefarbtiefe? vielleicht mit mediainfo .

Um die Qualität verschiedener Codierungen derselben Quelle zu vergleichen, messen Sie den SSIM oder PSNR jeder Codierung relativ zur Quelle. x264 kann diese beiden Metriken während des Codierungsprozesses messen. Es gibt andere Tools zum Vergleichen zweier bereits erstellter Videodateien, um diese Qualitätsmetriken zu messen, aber ich habe sie nicht verwendet.

Verwenden Sie für ffmpeg -ssim 1 -psnr -tune ssim. (Nicht verwenden, -tune ssimaußer beim Benchmarking dieser Metrik. Es aktiviert standardmäßig psychovisuelle Optimierungen, die eine Ausgabe erzeugen, die für Menschen besser aussieht, aber gemäß dieser Metrik mathematisch weniger ähnlich ist.)

SSIM und PSNR sind ungefähr das Einzige, was Sie verwenden können, wenn Sie mit Bitraten arbeiten, die weit über die visuelle Transparenz hinausgehen. Google auf diesen für weitere Informationen.

Um die Verlustfreiheit zu testen, können Sie den -f framemd5Codec von ffmpeg verwenden, um sicherzustellen, dass h.264 bitidentisch mit der Eingabe dekodiert. ( Ein Beispiel finden Sie in dieser Frage . Stellen Sie sicher, dass Sie für alle Tests dasselbe -pix_fmt verwenden, da verschiedene Decoder möglicherweise dieselben Daten unterschiedlich packen.)

Oh, lesen Sie einfach die Antwort von Prof. Sparkles. Wusste nicht, dass Sie schließlich verlustfrei ausgeben. Sie schießen sich nur selbst ins Knie, wenn Sie unterwegs verlustbehaftete Codecs verwenden. Der verlustfreie Codec muss alle unsichtbaren Blockierungs- / Klingelartefakte codieren, die von den verlustbehafteten Codecs hinterlassen werden, sodass Sie normalerweise größere Dateien von Ihrem verlustfreien Codec erhalten, wenn Sie ihn mit Eingaben füttern, die einen verlustbehafteten Codec anstelle der ursprünglichen Quelle durchlaufen haben.

Wenn Sie also h.264 verwenden möchten, verwenden Sie verlustfrei. ( ffmpeg -i in -preset ultrafast -qp 0 out). (Langsamere Voreinstellungen bieten nur eine winzige Verbesserung der Komprimierung für verlustfrei. Verwenden Sie Ultrafast jedoch niemals für etwas anderes als verlustfrei.)