Hallo,
in diesem Video wird empfohlen das man sein Footage (in meinem Fall H.264 mit Lumix G81) in den ProRes Codec wandeln sollte, da es das arbeiten in Premiere wohl performanter machen soll.
Wenn ich mich an die Settings im Video halte (Screenshot) bemerke ich allerdings einen Qualitätsverlust und die Dateien sind deutlich kleiner.
Aufnahmen von einem Horizont z.B. sichtlich verpixelt.
MediEncoderProRes.jpg
Hat da jemand Erfahrung von euch?
Muss ich evtl. einen anderen ProRes Codec nehmen? evtl. ProRes 4444 oder gar ProRes 4444 XQ?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Mac.
Proxy-Workflow lese ich mir mal durch.
Ich versuch heute Abend mal zwei Beispiel Clips hochzuladen wo man den Qualitätsverlust optisch ganz gut ausmachen kann.
burn4ever hat geschrieben: ↑Do 04 Okt, 2018 07:53
...wird empfohlen das man sein Footage (in meinem Fall H.264 mit Lumix G81) in den ProRes Codec wandeln sollte...
Muss ich evtl. einen anderen ProRes Codec nehmen? evtl. ProRes 4444 oder gar ProRes 4444 XQ?
in welcher Verpackung (container) kommt denn das footage aus der cam?
Bevor ich sowas umcodiere würde ich erst mal eine verlustfreie Umverpackung
testen. Wenn da AVC/AAC drin ist (bzw /AC3) dann
versuche mal in MPEG4-V2 einzutüten od auch einen Transportstream (*.ts).
Beides enthält bessere Bild-Indexing-Infos, was für die Positionierung innerhalb
des streams effizienter ist. Aber so entstehen keine neuen Generationssverluste.
Wenn die chroma-Info gar nicht erst dichter vorliegt (zB 4:2:0) verbessert sich
auch nix bei der Umkodierung in ein höheres Chroma-Format.
Es würde nur (etwas) schlechter werden.
Ich versuch heute Abend mal zwei Beispiel Clips hochzuladen wo man den Qualitätsverlust optisch ganz gut ausmachen kann.
wie/wohin hochladen?
YT macht üblicherweise zuerst eine eigene Rekodierung.
Das sagt dann nix mehr über die Probleme der Originalqualität aus.
dosaris hat geschrieben: ↑Do 04 Okt, 2018 09:51
Bevor ich sowas umcodiere würde ich erst mal eine verlustfreie Umverpackung
testen. Wenn da AVC/AAC drin ist (bzw /AC3) dann
versuche mal in MPEG4-V2 einzutüten od auch einen Transportstream (*.ts).
Beides enthält bessere Bild-Indexing-Infos, was für die Positionierung innerhalb
des streams effizienter ist. Aber so entstehen keine neuen Generationssverluste.
pinzipeill hast du damit schon recht, nur dass halt MPEG transportstreams auch nicht unbedingt ein optimales format darstellen bzw. die meisten programme für die diesbezügliche handhabung nicht wirklich optimiert sind und tlw. probleme auftreten können, weil dort verschiedene payloads nicht erlaubt sind (bspw. AC3).
die problematik komprimierten tons. wird im video-umfeld überhaupt gerne unterschätzt. ich hab aber letzter zeit beim herumspielen mit ganz schwachbrüstigen mini-rechern fürs live streamen die beobachten können, dass tlw. die audio-kompression ausschlaggebend für rechenkapazitätsengpässe werden kann. das ist zwar jetzt nicht unbedingt ohne weiteres auf desktop-anwendungen umlegbar, wo man diesbezüglich nicht ganz so eingeengt ist, trotztem sollte man es im hinterkopf behalten -- und unkomprimierter tonspuren fallen ja meistens in bezug aufd die dateigrößen ohnehin nicht ins gewicht.
dosaris hat geschrieben: ↑Do 04 Okt, 2018 09:51
Wenn die chroma-Info gar nicht erst dichter vorliegt (zB 4:2:0) verbessert sich
auch nix bei der Umkodierung in ein höheres Chroma-Format.
Es würde nur (etwas) schlechter werden.
prores gibt's ohnehin nicht in 4:2:0 -- wobei das wohl weniger eine frage der qualität ist, sondern vielmehr mit dem technischen umstand zu tun hat, dass in 4:2:2 alle bildzeilen eine einheitliche länge im datenstrom besitzen, während bei 4:2:0 jede zweite zeile eine andere länge besitzt. das ist nicht immer vorteilhaft.
wichtiger ist aber, dass man beim enstprechenden umkodieren von 8bit h.264 material aus der kamera durchaus sinnvoll zu 10bit mezzanine files wandeln sollte. das hat damit zu tun, dass fast alle besseren consumer cameras in den betreffenden hoch komprimierten aufzeichnungen dither-techniken nutzen, um bspw. banding am himmel zu unterdücken. derartiges geht beim reencoden mit anderen kompressionstechniken gerne verloren. die 10bit-nutzung ist hier die naheliegendste lösung, um entsprechenden nuancen auf anderem weg zu bewahren.
Seine Kamera macht stinknormales AVCHD oder mp4. Um was es genau geht, erfahren wir ja vielleicht noch. Auch, was für ein Mac da am Start ist. Was älteres? Diese völlig normalen Formate sollten auch ohne Wandlung problemlos laufen.
Jott hat geschrieben: ↑Do 04 Okt, 2018 11:53
Seine Kamera macht stinknormales AVCHD oder mp4. Um was es genau geht, erfahren wir ja vielleicht noch. Auch, was für ein Mac da am Start ist. Was älteres? Diese völlig normalen Formate sollten auch ohne Wandlung problemlos laufen.
Also,
clips als mp4 FHD/50p: 28Mbps.
iMac (mitte 2011 mit SSD aufgerüstet). 2,7 GHz Intel Core i5, 16GB Ram.
Im Prinzip läuft ja auch mein Projekt aber wenn ich performance sparen kann, nehem ich das natürlich gerne mit.
Mitte 2011 ist natürlich schon ein Oldie. Da fährst du mit einem Produktionscodec sicher besser, egal mit welchem. Aber zurück zu ProRes: korrekt gewandelt ist da garantiert kein Unterschied zu sehen.
Also das GOP-Codecs nicht die beste Schnittperformance bieten ist bekannt.
Da flutscht Prores deutlich besser. Aber jede Umrechnung mindert etwas die Qualität.
Ich würde mir diesen Schritt sparen. Außer Proxys natürlich, die schaden ja nicht der Quali.
Jott hat geschrieben: ↑Do 04 Okt, 2018 21:53
Mitte 2011 ist natürlich schon ein Oldie. Da fährst du mit einem Produktionscodec sicher besser, egal mit welchem. Aber zurück zu ProRes: korrekt gewandelt ist da garantiert kein Unterschied zu sehen.
Hmm, dann werde ich heute noch mal ein paar Tests fahren.
Das einzige wo ich mir nicht sicher bin ob ich die Clips mit 8 oder 16 bpc rendern soll
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
