WICHTIG: PROBLEM GELÖST (NOCH EIN PAAR FRAGEN), ICH HABE EINIGE INFOS UNTER DEM URSPRÜNGLICHEN POST ALS UPDATE GEPOSTET, WENN JEMAND DIES NÜTZLICH FINDET:
Kurze Frage: Was sind die Vorteile der Verwendung der gängigsten Nicht-Long-GOP-Codecs für die Bearbeitung (DNxHD/DNxHR und Prores) im Vergleich zu Intra-Frame-H.264 mit einer hohen Bitrate? Theoretisch ist die Komprimierungsfähigkeit bei H.264 besser, auch wenn sie nur Intra-Frame ist, und allein durch die Intra-Frame-Komprimierung sollte die Wiedergabeleistung während der Bearbeitung der der beiden anderen Codecs entsprechen. Außerdem unterstützt H.264 bis zu 12 Bit und 4:4:4 (also flexibel). Ich habe über diese Codecs gelesen, was ich konnte, aber ich muss noch einen Grund dafür finden, warum Intra-Frame-H.264 nicht umfassender für die Bearbeitung verwendet wird.
Fürs Protokoll, ich frage das, weil ich ein HDR-Projekt von einem H.264 High 10 UHD 4:2:0-Video starte und zwei Probleme habe: Wenn ich versuche, mit Proxys (mit DNxHR oder Prores ), erhalte ich schwerwiegende Synchronisierungsprobleme zwischen der Quelldatei und den Proxys, sodass ich sie nicht richtig bearbeiten kann. Und wenn ich die Quelldatei in eine Datei transcodiere, die diese Synchronisierungsprobleme nicht hat (wie DNxHR, mit DNxHR auch für Proxys), verliere ich die HDR-Daten und das Video sieht aus wie ein SDR-Video (und das passiert mit jedem Codec, nicht nur DNxHR. Ich konnte die HDR-Informationen der Quelldatei mit keinem Codec beibehalten und habe es mit FFmpeg und Adobe Media Encoder versucht), aber das ist ein Problem für einen anderen Beitrag. Die Sache ist, dass ich das Originalmaterial als Quelldatei verwenden muss, aber ohne Proxys nicht auf diese Weise bearbeiten kann (offensichtlich ist die Wiedergabe extrem langsam). Daher habe ich mich gefragt, ob die Transcodierung der Quelldatei in ein Intra-Frame-H.264-Video und die Arbeit damit (und ohne Proxys) Auswirkungen auf die endgültige Qualität haben würde. Ich habe keine Informationen gefunden, die Intra-Frame-H.264 mit anderen Zwischen-Codecs in Bezug auf Qualität und Leistung vergleichen.
Vielen Dank im Voraus.
UPDATE (03.02.20):
Ich habe einige Tests durchgeführt, um zu sehen, wie sich Intra-Frame H.264 mit Adobe Premiere Pro 2020 verhält:
1)Ich habe das Originalmaterial (H.264, MKV-Container, HDR, 10 Bit, UHD, 4:2:0, VBR) mit FFmpeg in eine Intra-Frame-"Version" der Datei transkodiert, ohne eine andere Einstellung zu ändern (gerade hinzugefügt -intra zu meiner ursprünglichen FFmpeg-Befehlszeile). Ich habe CRF 18 und veryslow als Preset verwendet (ich habe eine sehr gute CPU, also wurde die ganze Datei über Nacht transkodiert). Ich habe die Datei dann in Adobe Premiere Pro 2020 importiert. Zunächst muss ich sagen, dass ich noch nicht mit der Bearbeitung begonnen habe, aber zumindest konnte ich feststellen, dass sie kompatibel war und sich beim Testen der Wiedergabe wie ein Intra-Frame-Video verhielt ( Ich konnte sehr schnell vorwärts und rückwärts gehen). Ich konnte auch keinen Qualitätsunterschied im Vergleich zum Originalmaterial feststellen. Mit anderen Worten, Intra-Frame-H.264 scheint bisher eine gute Alternative zu anderen Zwischencodecs wie Prores oder DNxHD/DNxHR zu sein. In der Tat,
2)Ich weiß, dass zusätzliche Transkodierungsschritte qualitativ nie eine gute Sache sind, aber da ich sowieso in ein Intra-Frame-Video transkodieren musste, habe ich einen weiteren Test gemacht und das Originalmaterial mit FFmpeg (mit libx265) in ein HEVC-Video transkodiert, wobei ich alles beibehalten habe die ursprünglichen Einstellungen. CRF verwendet wurde, war 18, mit veryslow auch als Voreinstellung. Ich habe das main10-intra-Profil von x265 verwendet. Dann habe ich dasselbe mit einem anderen Video gemacht, das SDR war. Es hat erwartungsgemäß etwas länger gedauert, aber ich wollte dies aus mehreren Gründen tun: Erstens, weil ich wissen wollte, wie Adobe Premiere Pro 2020 mit einem H.265 HDR UHD Intra-Frame-Video umgeht. Zweitens, weil ich gelesen habe (und mich diesbezüglich nicht zitiere), dass viele nach der Transcodierung eines 8-Bit-Videos in ein 10-Bit-Video eine Qualitätssteigerung wahrnehmen, aufgrund des breiteren Farbraums, der es dem Encoder ermöglicht, während der Transcodierung aus viel mehr Farben auszuwählen, wodurch Banding reduziert wird. Nun, ich habe qualitativ keinen Unterschied wahrgenommen (im Vergleich zur Intra-Frame-H.264-Datei und zum Originalmaterial, sowohl bei den HDR- als auch bei den SDR-Dateien), aber die Dateigrößen waren offensichtlich kleiner und zumindest bei mir PC schnitten sie auf Premiere Pro sehr gut ab (die Wiedergabe war so schnell wie bei den Intraframe-H.264-Videos). Offensichtlich zeigt die HDR-Videowiedergabe nicht die richtigen Farben, aber das ist eine Einschränkung von Premiere aufgrund der Art und Weise, wie es mit Farbräumen umgeht (noch kein REC2020). aber die Dateigrößen waren offensichtlich kleiner und zumindest auf meinem PC haben sie unter Premiere Pro sehr gut funktioniert (die Wiedergabe war so schnell wie bei den Intra-Frame-H.264-Videos). Offensichtlich zeigt die HDR-Videowiedergabe nicht die richtigen Farben, aber das ist eine Einschränkung von Premiere aufgrund der Art und Weise, wie es mit Farbräumen umgeht (noch kein REC2020). aber die Dateigrößen waren offensichtlich kleiner und zumindest auf meinem PC haben sie unter Premiere Pro sehr gut funktioniert (die Wiedergabe war so schnell wie bei den Intra-Frame-H.264-Videos). Offensichtlich zeigt die HDR-Videowiedergabe nicht die richtigen Farben, aber das ist eine Einschränkung von Premiere aufgrund der Art und Weise, wie es mit Farbräumen umgeht (noch kein REC2020).
3)Da ich zuvor Farbprobleme beim Umcodieren nach DNxHR hatte und das nicht lösen konnte, begann ich zu glauben, dass dies möglicherweise mit dem Chroma-Subsampling zu tun hat (keine der DNxHR-Varianten unterstützt 4:2:0, was das Subsampling der Originalvideo). Das war ein weiterer Grund, es mit Intra-Frame H.264 (oder H.265) zu versuchen, um zu sehen, ob die Transcodierung auf 4:2:0, 4:2:2 oder 4:4:4 einen ähnlichen Unterschied in den Farben im Vergleich zu machte DNxHR. Es stellt sich heraus, dass beim Transkodieren auf 4:2:0 (mit H.264 oder H.265 als Codecs) die Farben genau so aussehen wie das Originalmaterial, und sowohl 4:2:2 als auch 4:4:4 sehen viel aus wie das DNxHR-Video (Farben verwaschen). Ich kann keinen Unterschied zwischen 4:2:2 und 4:4:4 erkennen, aber im Vergleich zu 4:2:0 ist der Unterschied riesig. Ich wollte das Video nie hochskalieren, es lag nur daran, dass DNxHR 4:2:0 nicht unterstützt, aber so einen unterschied hätte ich nie erwartet. Und wenn es am Upsampling lag, verstehe ich nicht ganz, warum 4:2:2 und 4:4:4 genau gleich aussehen. Vielleicht ist es eine Art FFmpeg-Fehler, der beim Upsampling den Farbraum durcheinander bringt, idk.
Wie auch immer, jetzt habe ich funktionierende H.264- und H.265-Intra-Frame-Videos ohne Farbprobleme (die Dateien wurden visuell mit Mediainfo und mit der Registerkarte Lumetri-Bereiche von Premiere überprüft. Sie haben tatsächlich alle für HDR erforderlichen Metadaten beibehalten). , ohne Synchronisierungsprobleme (ich habe auch ein paar Proxys mit genau denselben Einstellungen erstellt, aber nur mit geringerer Auflösung. Sie synchronisieren perfekt mit der Quelldatei), mit kleinerer Dateigröße als mit DNxHR und Prores, und das funktioniert sehr gut unter Premiere Pro 2020 während der Vorschau (vielleicht nicht mit einer minderwertigen CPU, ich weiß es nicht). Man könnte also sagen, dass mein Problem in der Zwischenzeit (ich muss mit der Bearbeitung beginnen, vielleicht werde ich unterwegs auf einige Probleme stoßen. Und ich habe den Export aus Premiere mit diesen Dateien noch nicht getestet) mein Problem gelöst ist.
Aber meine Frage bleibt nach diesen Tests: Warum sind Intra-Frame-H.264 oder Intra-Frame-H265 nicht mehr als Alternativen zu DNxHR oder Prores (den am häufigsten verwendeten Zwischencodecs) erweitert? Ich sehe nur Vorteile: kleinere Dateigröße, gute Wiedergabeleistung, sehr gute Qualität (und wenn Sie genug Speicherplatz haben, können Sie sogar eine verlustfreie Intra-Frame-H.264-Datei erstellen, wenn Sie möchten), sie bewahren das HDR Daten, und beide Codecs sind sehr bekannt und erweitert. Sie haben sogar ihre eigenen Intra-Frame-Profile (z. B. hat H.265 main10-intra, main444-10-intra usw.). Die Transkodierungszeiten sind meiner Erfahrung nach, zumindest mit FFmpeg auf einem PC, nicht so unterschiedlich im Vergleich zu DNxHR oder Prores. Gibt es einen Grund dafür, dass dies nicht der ideale Weg zum Bearbeiten ist, abgesehen von der Tatsache, dass diese Intra-Frame-"Versionen" von H.264 und H.
Danke, jeder Einblick in diese würde geschätzt werden. Und es macht mir nichts aus, die von mir verwendeten FFmpeg-Befehle zu teilen, wenn jemand dies nützlich findet.
ProRes/CineForm/DNxHR haben sich aufgrund der Plattformen, die sich für ihre Verwendung entschieden haben, durchgesetzt. Ursprünglich hatte H.264 keine 10-Bit-Implementierungen und H.265 existierte nicht.
Diese Formate sind so konzipiert, dass sie einer erneuten Codierung standhalten und gleichzeitig sehr schnell zu codieren/decodieren sind. Sie werden nicht mühsam für die bestmögliche Qualität bei einer bestimmten Bitrate optimiert.
Mehrere Kameras können Dateien in All-Intra H.264 speichern. Ich weiß, dass Panasonic und Sony es unterstützen. Sony nennt es XAVC SI. Das ist nur ihr Markenname für H.264 All-Intra mit 10-Bit-, 12-Bit-, 422- und 444-Unterstützung. Und es unterstützt PCM-Audio, das eigentlich nicht mit der MP4-Container-Spezifikation kompatibel ist. Diese Formate setzen sich in Kameras durch, da die Kameras sehr spezifische Anforderungen an die Bitrate haben, um auf eine SD-Karte zu schreiben. Aber wenn Sie sich dann einen externen Rekorder wie den Ninja V ansehen, der auf eine SSD aufzeichnen kann, wird dieser in ProRes/DNxHR aufzeichnen, weil er mit der höheren Bitrate umgehen kann – und weil niemand ausgehen wird, um etwas zu kaufen, das angeblich unterstützt XAVCSI. Die Leute wollen ProRes/DNxHR, weil es ihr Leben einfacher macht.
Wenn Sie also die All-Intra-Datei in bester Qualität wünschen, können Sie diese sicherlich bekommen. Sie können es verlustfrei machen. Sie können ein "sehr langsames" FFMPEG-Rendering durchführen. Premiere/Resolve werden jedoch nicht die Option hinzufügen, die ganze Nacht über Proxy-Rendering durchzuführen.
Hier ist eine sehr gute Diskussion über die Qualität von All-Intra H.265 vs. H.264 vs. ProRes: https://www.eoshd.com/comments/topic/46562-prores-vs-h264-vs-h265- und-ipb-gegen-alle-ich-wie-gut-sind-sie-eigentlich/
Der Grund, warum H.265 nicht viel besser ist als H.264, liegt darin, dass die meisten Komprimierungsgewinne in neueren Codecs aus der fortgeschrittenen zeitlichen Komprimierung stammen und All-Intra per Definition keine zeitliche Komprimierung hat.
Vielleicht werden wir in Zukunft mehr Standard-All-Intra-Formate haben, aber das wird wahrscheinlich etwas nach HEVC sein. Es ist wohl ein Vorteil, Archivmaterial in einem All-Intra-Format aufzubewahren, mit dem man einfach arbeiten kann. Ein All-Intra-Format hat weniger Macken und eignet sich in einigen Fällen möglicherweise besser zum Hochladen auf YouTube, je nachdem, wie es mit der Transcodierung zurechtkommt. Aber das sind Grenzfälle. Die All-Intra-Version ist per Definition von geringerer Qualität für eine bestimmte Bitrate.
Der wahre Albtraum – der Sie überhaupt dazu gebracht hat, die Frage zu stellen – ist der Umgang mit diesen HDR-Metadaten. Es ist alles ein Haufen Voodoo, den Sie vielleicht mit ffprobe, mkvmerge und mkvpropedit aussortieren können.
Sie müssen herausfinden, was Ihr eigentliches Problem ist: Welche Metadaten enthält die Datei? Handelt es sich um Tags im Videostream oder um Tags in einem separaten Nebendatenstrom? Sie sollten in der Lage sein, FFMPEG zu erhalten, um dies zu erhalten. Aber was in einem Containerformat funktioniert, funktioniert möglicherweise überhaupt nicht für ein anderes Containerformat.
Es sieht so aus, als würde Premiere Ihre Quelldatei nicht mögen und die Synchronisierung vermasseln, und FFMPEG mag Ihre Quelldatei nicht und vermasselt die Metadaten. Wo genau kommt diese Quelle her?
stib
Raulo1985
Raulo1985