Hallo,
ich habe jetzt bereits des öfteren gelesen dass man vor der Postproduktion h.264 Clips in zB. ProRes umcodieren sollte. Wozu ist das gut? Man kann die komprimierten Aufnahmen doch nicht in ihrer Qualität steigern, oder doch?
Man kann die komprimierten Aufnahmen doch nicht in ihrer Qualität steigern, oder doch?
Nö, kann man nicht.
Aber manchmal bietet es sich für den Workflow an, auf einen sogenannten Intermediate-Codec zu wechseln (sind z.B. nicht so prozessorintensiv)
Stimmt es denn auch dass ProRes "verlustfreieres" bearbeiten ermöglicht?
Ganz im Gegenteil.
Durch das Transcodieren hast Du die Nachteile BEIDER Verfahren in Deinem Bild und verlierst die Vorteile die H.264 gegenüber H.262, dessen Codierschema ProREs zugrunde liegt, mit sich bringt.
Solche Intermediate Codecs bieten nur Vorteile auf schwachen Rechnersystemen, die es heutzutage aber nicht mehr allzuoft geben dürfte.
Wenn Du also einen halbwegs zeitgemäßen Rechner hast und Dein NLE natives H.264 unterstützt, lass die Finger von Transcodierungen.
WoWu hat geschrieben:Wenn Du also einen halbwegs zeitgemäßen Rechner hast und Dein NLE natives H.264 unterstützt, lass die Finger von Transcodierungen.
Hallo Wolfgang - und was ist beispielsweise mit DNxHD(Codec)+MXF OP1a(Container)?
Hier unterstützt doch Premiere das "intelligente Rendern", was ja soviel bedeutet: alles was keine Veränderungen aufweist, wird nicht "angefasst" - nur die Effekte (z.B. Blenden). Wobei ich festgestellt habe (nur anhand der Rendergeschwindigkeit), dass selbst grading und scalieren "durch zu rutschen" scheinen. Aber das kann natürlich auch am schnellen Rechner ;) liegen bzw. bei diesem Codec wird ja nicht mehr groß "ein- und ausgepackt" - oder?
Was ich eigentlich sagen will ;) - ich habe das Gefühl, dass die Bildqualität (insbesonder das branding in den Himmelsstrukturen bei 8Bit-Material, ganz extrem bei der Gopro 4) in den Generationen mit Verwendung (Reiter Mediaencoder: "Sequenzeinstellung beibehalten") des h.264 wesentlich schneller "kippt" als bei den Generationen von der Kombi DNxHDMXF OP1a. (sch. Schachtelsatz, sorry)
Sehe ;) ich das falsch oder könnte das ein Argument sein, gleich z.B. nach DNxHDMXF OP1a zu transcodieren und erst am Ende wieder einen h.246-File zu erstellen?!
Da sitzen jetzt mehrer Fragen verschachtelt ineinander.
Du sprichst "intelligentes Rendering" an. Dabei legt der Rechner -vereinfacht gesprochen- alle Effekte und Bearbeitungen quasi in einer Liste ab und führt das Rendern erst auf der Basis des URsprungs,steriles aus, wenn das final Rendering ausgeführt wird.
Dadurch werden Rundungsfehler, die bei Zwischenrendering auftreten und so von Renderprozess zu Renderprozess sich vergrößern, vermieden.
Das Andere ist das "smart Rendering", dabei werden unveränderte Teile des Originalmatrials nur im Multiplex eingefügt.
Das funktioniert ab nur mit Strukturen, die eine gleichmäßige GOP aufweisen, also MPEG2 basiertes Material.
In MPEG4 Material gibt es solche konstanten Strukturen genau genommen nicht mehr, weil es die klassische GOP gar nicht mehr gibt und I Frames auch nicht mehr den Stellenwert haben, wie in MPEG2.
Dazu kommt, dass alle Werte, sofern sie nicht verändert wurden, ohnehin in einem Render nicht verändert werden, also Smart Rendering ziemlich überflüssig ist. Das ist eigentlich auch ein Relikt aus der Zeit, als Rechner noch schwach auf der Brust waren und man ständig zwischen gerendert hat, um Content überhaupt sichtbar zu machen.
Heutzutage können Rechner das 'on fly' wobei jedes Zwischenrendern sowieso überflüssig ist und "intelligentes Rendern" dem Rechnung trägt.
Was das Banding betrifft, bist Du mit 8Bit Material sowieso immer im kritischen Bereich, sobald Du Veränderungen am Material vornimmst denn Banding entsteht, wenn Werte im Postprozessing zusammengefasst oder gespreizt werden.
Bei 8Bit Material sollten die Aufnahmen möglichst so gemacht werden, wie sie hinterher auch ohne viel Bearbeitung aussehen sollten.
Das liegt in der Natur von 8Bit.
Was MXF OP1 angeht ... das ist lediglich ein Container und 1a ist ein "delivery" Container, also das Einfachste, was man sich vorstellen kann und auch eigentlich nur geeignet, um eine Videospur und ein Stereopärchen Audio von A nach B zu übertragen.
Mehr kann der Container nicht.
WoWu hat geschrieben:Da sitzen jetzt mehrer Fragen verschachtelt ineinander.
...habe ich mir doch beinah gedacht, trotzdem danke! :)
WoWu hat geschrieben:Du sprichst "intelligentes Rendering" an. Dabei legt der Rechner -vereinfacht gesprochen- alle Effekte und Bearbeitungen quasi in einer Liste ab und führt das Rendern erst auf der Basis des URsprungs,steriles aus, wenn das final Rendering ausgeführt wird.
Dadurch werden Rundungsfehler, die bei Zwischenrendering auftreten und so von Renderprozess zu Renderprozess sich vergrößern, vermieden.
...das klingt doch interessant. Das würde ja bedeuten, dass ich einen zu rendernden File von Premiere unter Verwendung dieses Codecs+dem Einfachcontainer ;) an den Mediaencoder übergebe, um es anschließend erneut als DNxHDMXF OP1a auszugeben, alles beim "alten" bleibt und erst wenn ich final rendern möchte (z.B. in .h264), die eigentliche Kodierung beginnt?! Klingt doch gut?!
D.h. ich könnte (und ich habe das Gefühl, ich kann ;) x-beliebige Zwischenergebnisse produzieren ohne das eigentliche Material anzufassen? Ergo, habe ich keine Transcodierverluste (bis zum Ende der Schnittorgie). Also eine Art Proxy für den Codec - oder ist es gar richtiges Proxy??
Um es nochmal für mich auf den Punkt zu bringen: dann bleibt ja h.264 im Grunde IMMER h.264. Das beschäftigt mich sehr, denn es würde sich mit meinen Erfahrungen decken.
Bis jetzt habe ich auf den cineform-Codec für "Zwischenlösungen" geschworen. Aber nachdem ich jetzt viel Gopro-Material verarbeiten musste, war bereits nach der 2. Render-Generation unter dem cineform in den Flächen (Himmel) eine deutliche Verschlechterung in Form von Artefakten zu sehen. Mache ich das in "neuer" besagter Variante, kann ich das nicht feststellen.
Nun könnte es generell an Unterschieden/Qualitäten von den verwendeten Codecs liegen (wobei der cineform, nicht der ist, den es frei zu downloaden gibt - also auf einem echten broadcast-Industriestandart beruht) und der DNxHD ja auch nicht von schlechten Eltern stammt ;).
Oder - h.264 ist nicht gleich h.264 bzw. machen die Hersteller kameraseitig noch ihre eigenen Parameter "dazu" (fängt ja schon mit der Bit-Rate an). Kommen gewisse "Umstände" dann zusammen - schwupps, ist es Essig mit der heilen h.264-Generations-Welt.
WoWu hat geschrieben:Was das Banding betrifft, bist Du mit 8Bit Material sowieso immer im kritischen Bereich, sobald Du Veränderungen am Material vornimmst denn Banding entsteht, wenn Werte im Postprozessing zusammengefasst oder gespreizt werden.
Bei 8Bit Material sollten die Aufnahmen möglichst so gemacht werden, wie sie hinterher auch ohne viel Bearbeitung aussehen sollten.
Das liegt in der Natur von 8Bit.
..das kann ich inzwischen 100% unterschreiben. Bisher wusste ich nur nicht, woher die Fehler kamen. Habe es auf alles mögliche geschoben, bis slashcam den interessanten und heiß diskutierten Artikel herausgebrachte, der 8Bit und 10Bit an hand von Bildern verglichen hat. Selbst wenn da noch das eine oder andere auslegungswürdig gewesen ist - aber die Grundrichtung stimmte auf jeden fall...
Da liegst Du im Augenblick völlig Richtig, zumal bei Cineform noch erschwerend hinzu kommt, dass ein völlig anderes Transformationsverfahren zur Anwendung kommt und in der Kombination aus DCT und DWT nicht nur unterschiedlich Artefakte entstehen sondern auch Bildelemente (speziell in der DWT) immer "weicher" werden, was am Ende einer Bearbeitung dann zu einem ziemlich merkwürdigen Bild führt.
Viele schwören ja auf so einen weichen Charakter und solange man in Wavelet bleibt mag das auch alles noch prima aussehen, aber wenn dann die DCT Artefakte hinzu kommen, also nach MPEG transcodiert wird, dann ist das, wie Du schon gesagt hast, nicht mehr lustig.
Eine DWT funktioniert wirklich prima, wenn man in hohen Datenraten bleibt, aber wehe, wenn das runter geht.
Und was den H.264 angeht ... Ein Codec ist immer nur so gut wie die Implementierung durch den Hersteller. MPEG gibt ja nur das Schema vor und definiert den Bitstream und stellt so etwas wie einen "Werkzeugkasten" bereit.
Wie solche Werkzeuge allerdings eingesetzt werden, wie die Speicher und Verfahren genutzt werden, entscheidet allein der Hersteller bei der Implementierung.
Also, nicht jede H.264 Implementierung ist gleich gut.
Ist sie gut gemacht, ist das Ergebnis deutlich besser, als alles, was wir zuvor an Codecs gehabt haben, was z.B. bei HEVC noch lange nicht so weit ist.
Und was man bei der ganzen Transcodierung, auch hin zu I-Frame Intermediates nicht vergessen darf .... Die sind nur gut, solange man nicht von oder nach GoP orientierten Varianten transcodiert, denn auch I-Frame Codecs sind (wenn auch leicht) komprimiert, aber mit dem Schwerpunkt auf statischen Bildelementen, wohingegen GoPs ihren Schwerpunkt auf dynamischen Elementen haben.
Mischt man sie, hat man beide Elemente verschlechtert
Bleibt man innerhalb eines Schemas, begrenzt sich die Degenerieren des Bildes.
Man darf also auf sowas wie "lossless" nicht reinfallen ... das gilt nur, wenn kein anderer Codec oder anderes Codierschema im Spiel ist.
Smart Rendern beruht immer auf einer festen GOP Struktur, die es in H.264 gar nicht mehr gibt.
Ansonsten erklär mal, wie beispielsweise ein H.264 Slice ohne das Restbild in einen Multiplex "smart" übernommen den kann.
Außerdem ist in H.264 Eine vorwärts Prädiktion möglich.
Was macht ein Smart Renderereignissen da?
Fängt er an zu raten ?
Und was die Bilddegeneration angeht, hängt das immer von den Fehlern ab, die zwischen den Renderereignissen entstehen.
Deshalb hat H.264 ja auch eine ICT bekommen, die ohne Rundungsfehler und nur noch mit Additionen und Shifts arbeitet.
Aber bemerkst du nicht, dass Blueplanet merkwürdigste Schlüsse aus deinen Posts zieht. Der scheint zu glauben, bei intelligentem Rendern kann er machen was er will ;)
Gibts aber so gar nicht z.B. bei Adobe ;)
Ich habe daraus nur gelesen, dass er erkannt hat, woher die Fehler kommen und keineswegs, dass er machen kann, was er will.
Und wenn er "intelligentes Rendern" nutzt, dann ist das mehr als vernünftig und wird ihm das Bild deutlich weniger "anfassen".
Wir haben das vor 10 Jahren im Quantel schon benutzt. Nur hatte es da keinen so werbewirksamen Namen sondern Du musstest Zwischenrenderprozesse extra einleiten, was auf's Selbe hinausläuft.
Und es ist eben ein Unterschied, ob ein NLE auf neu hergestellte Inserts zugreift oder nur auf die Filter und Intents.
Weil dein Quantel das schon vor 10 Jahren konnte, kannst du doch nicht ernsthaft annehmen, dass das jetzt in jedem NLE so ist.
Und das intelligentes Rendern in Premiere was anderes bedeutet, sollte auch langsam angekommen sein.
Niemand hat hier geschrieben, dass es mit h264 Material funktioniert. Hier steht nur, dass Adobe smart Rendern intelligentes Rendern nennt. Oder nicht *nennt*, sondern *übersetzt*?! Vielleicht, nur mal so, möglicherweise... ;)
...boaah Jungs, ich will nicht machen, was ich will - ich möchte es richtig machen und es wäre toll, wenn ich dafür eine begreifbare Erklärung bekomme.
Meine Versuche und Ergebnisse habe ich ja bereits geschildert und was Wolfgang dazu informiert, ist für mich im Ansatz nachvollziehbar. Dabei ist mir völlig klar, dass ich selbst beim "intelligentesten Rendern" (wie ich es nach Wolfgangs Ausführung entnehme) nicht unendliche Möglichkeiten haben werde. Nur scheint es trotzdem mehr Reserven zu beinhalten, als wenn ich mich in einem komplett anderen Codec (cineform) und nicht dem intelligent-gerenderten kameraseitigen h.264 bewege.
Um es zusammen zu fassen:
-ist smart rendering nun die engl. Übersetzung für intelligentes Rendern?
-wenn ja, dann funktioniert es doch in meinen Beispielen prima
-wenn nein, wann rendere ich "smart" und an welcher Stelle "intelligent"?
-ist die Option im Mediaencoder "entspricht Sequenzeinstellung" smart-rendering oder ist das intelligentes Rendern incognito oder nehme ich doch lieber 100 Gramm Leberwurst ;))?
Benny92 hat geschrieben:Wie codiert man am besten um? Einfach nativ in zB. FCPX importieren und dann in ProRes exportieren?
H.264 rein in fcp x und schneiden, dann ausgeben, wozu du Lust hast.
Sollte sich der Rechner langsam anfühlen (was bei aktuellen nicht der Fall ist), dann das Material im Hintergrund zu ProRes ("optimierte Medien") wandeln lassen, das beschleunigt je nach Rechner erheblich. Du kannst dann jederzeit misstrauisch hin und herschalten zwischen Original und ProRes - und wenn du einen Unterschied findest, darfst du ihn behalten.
dienstag_01 hat geschrieben:Nein. Intelligentes Rendern ist die deutsche Ãœbersetzung von Smart Rendering (bei Adobe).
hmmm...wenn das so ist, dann wäre es bei mpeg4 -laut Wolfgang- im Prinzip nicht empfehlenswert anwendbar. Also nur bei mpeg2-Projekten.
Wie gesagt - ich kann bei smart Gerendertem mit h.264 über mindestens 2 Generationen hinweg nichts Nachteiliges (augenscheinlich!) erkennen.
Das mit den Farbkorrekturen und Tranformationen erscheint mir schleierhaft. Wenn es deiner Aussage nach neu berechnet werden MUSS, wird es doch komplett gemacht (angefasst) und es wird nicht nur das "Mäntelchen" darüber in die Färberei gegeben. Somit wäre das Smart-Rendern außen vor. Dem wiederum steht die Schnelligkeit des "angeblichen" Neuberechnens bei dieser Methode gegenüber.
Ganz anders, wenn ich h.264-Material mit Farbkorrektur und Transformation wieder in h.264 rendern lasse (die Option Smart-Rendern ist erst gar nicht vorhanden). Da liegen zudem zeitlich Welten zwischen - vom beschriebenen Verlusten über Generationen hinweg ganz zu schweigen.
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.
