slashCAM Forum

TomStg hat geschrieben:

blueplanet hat geschrieben:...hängt das mit meiner persönlichen Arbeitsweise in Premiere zusammen.

Ändere als Erstes Deine suboptimale Arbeitsweise:
Entweder benutzt Du für einige Teile Deines Projekts einen - nicht nur visuell sondern tatsächlich - verlustfreien Codec (zB Lagarith oder Uncompressed UYVY bzw keinen Codec = None) oder Du renderst das gesamte Projekt erst ganz am Ende des Workflows für die Ausgabe. Zwei Mal mit Verlust zu rendern, funktioniert nicht - selbst bei optimalen Codec-Einstellungen nicht, die hier offenbar noch gar nicht gewählt sind. Und Speicherplatz ist gar kein Argument gegen verlustfreie Ausgabe.

Statt Lagarith,das ich zwar auch einsetze aber nur für urspr.Analoges,würde ich hier eher auf den Canopus HQ [HQX] setzen.
Den gibts ja seit einem Jahr auch kostenlos.Für Win + Mac.
Da einfach die Settings richtig setzen.

Was jetzt: sind professionelle Intermediate Codecs nun Teufelszeug oder gar doch die ganz normale und überall in der realen Welt gängige Lösung des Problems? :-)

professionelle Intermediate Codecs

da gehört doch nebst Prores ja auch der Canopus HQ [HQX] dazu.
Interessant wurde es ja als er nicht nur für Edius Anwender frei zur Verfügung stand sondern seit geraumer Zeit auch kostenlos zu haben ist.

Warum wohl senden die Transponder Streams in Canopus HQ [HQX]

@Goldwingfahrer

Ganz herzlichen Dank für Deine Tips und da bald Weihnachten ist ;)...
vielleicht könntest Du evtl. noch ein bisschen aus dem Nähkästchen preisgeben bzw. mir die typischen Einstellungen für beide Codecs (HQX und Lagarith) verraten (siehe angehangene Screenshots). Das wäre super, denn mit den für mich kryptischen Bezeichnungen, kann ich nicht viel anfangen.

@TomStg

...ja, ich werde in mich gehen und den workflow gezielter abstimmen. Wenn man nicht losless ;) filmt, gibt es nur die Alternative zum Verlust, dass die Zwischenschritte optimiert werden. Im schlimmsten/kritischen Fall müssen halt diverse Szenen bis zur entgültigen Ausgabe uncompressed bleiben - das leuchtet mir so weit ein. Alles andere ist mal mehr oder weniger ein zufriedenstellender Kompromiss.

LG

WoWu hat geschrieben:Das ist so, wenn Du aus einem AVC Codec kommst denn allein die Bewegungsprädiktion und Farbauflösung werden zurückgeführt.
Bei schlichtem Material wahrscheinlich nicht wahrnehmbar aber bei kritischem Material schon.
(Und noch ein paar andere Punkte) Die beiden Sachen hab ich hier mal nur exemplarisch aufgeführt.
Genausowenig macht es Sinn, aus gemeinsamen Bewegungsvektoren wieder individuelle zu machen, die nur die Bandbreite drastisch erhöhen und jede Menge Fehler produzieren usw. usw.

Wieso wird die Farbauflösung zurückgeführt?

Angenommen, ich habe DNxHD als Intermediate um damit Effekte zu berechnen: Du sprichst von Fehlern, die bei der Umwandlung von AVCHD nach DNxHD zu erwarten sind. Sind diese Fehler nicht genauso zu erwarten, wenn ich meine Effekte auf das AVCHD Material direkt anwende?
Wenn nicht, warum nicht?

Mir erscheint dieser Verweis auf Fehler eher polemisch, da Fehler natürlich bei jeder Umwandlung/Berechnung entstehen können. Aber Berechnen muss ich ja.

@Goldwingfahrer

Ganz herzlichen Dank für Deine Tips und da bald Weihnachten ist ;)...
vielleicht könntest Du evtl. noch ein bisschen aus dem Nähkästchen preisgeben bzw. mir die typischen Einstellungen für beide Codecs (HQX und Lagarith) verraten (siehe angehangene Screenshots). Das wäre super, denn mit den für mich kryptischen Bezeichnungen, kann ich nicht viel anfangen.

sorry,hab ja noch ein Leben nebst den PCs.

Lagarith setze ich nur ein bei urspr.Analogem und in Interlaced vorliegend.
In Deinem Falle würde ich den HQ oder den HXQ einsetzen und auf Maximal fahren.
"Custom"......und bei "max size min" den Schieber ganz nach rechts ziehen,das wars.

@dienstag
Es gibt keine dynamischen Makroblockgrössen in MPEG2, anders als in H.264, wo die Makroblockgrössen dem Bildinhalt entsprechend fein angepasst werden.
Oder hast Du schon mal in einem der angesprochenen Intermediates etwas Anderes als 16x16 gesehen.
Die Konsequent ist klar ... überführt man eine solche feine Bewegungsauflösung in eine grobe Blockstruktur, verändern sich die Resultate entsprechend zum negativen und sind auch nicht mehr reproduzierbar.

was die Berechnung angeht, geht es weniger im die Rechenfehler die der Rechner verursacht sondern um die Fehler aus unterschiedlichen Algorithmen, beispielsweise in der DCT.
Eine Berechnung, die nur aus Additionen und Shifts besteht ist absolut reproduzierbar, anders als Algorithmen mit entsprechend vielen Rotationswinkeln.
Es geht im Unterschied um die Rückführungsgenauigkeit in den Frequenzbereich und wenn ich im Footage diese Möglichkeit durch Benutzung der entsprechenden DCT habe, sie aber bei der Umcodierung in eine DCT mit Rotation aufgebe, steigen damit die Fehler entsprechend an.
Es geht also nicht um die Rechenfehler die der Computer hinzufügt.
Aber die Unterschiede zwischen den Verfahren sind natürlich nicht auf diese kurzen Beispiele beschränkt ....

Für die Anzeige des Videos werden die Streams ja auch wieder bis auf Einzelbildebene dekodiert, weshalb sollte das nicht für die Umwandlung in einen anderen Codec funktionieren.

dank Wolfgang sind ein paar Details klarer geworden, prima, danke dafür.

Nun zur erforderlichen Quintessenz:
Welcher codec ist dann als intermediate geeignet, wenn die Quelle xavcs
ist, um die Grundlage für für die Erstellung von weiteren Distributionsformaten zu schaffen?
Bisher habe ich lagarith verwendet.

@dienstag
Einzelbild bezieht sich ja nur auf das Frameformat, hat aber nichts mit den darunter liegenden Verarbeitungsschicht zu tun.
Es ist eine Frage der Transformationsverluste.
Wenn Du in H.264 Makroblockgrössen von 4x4 hast und im Zielkodec nur noch 16x16 kannst, dann verändert sich die Auflösung des Codecs, also die Perfprmanz. (nicht zu verwechseln mit der spatialen Bildauflösung).

Hier geht es ja um Transcodierung, also um die Differenzen und die Fehler, die bei der Überführung eines Codecs in einen andern entstehen.
Das muss nicht immer auf den Codec zutreffen, wenn er als Sourcecodec benutzt wird und viele Codecs warten mit unterschiedlichen Vorteilen auf.
Nur bezieht sich das meistens darauf, dass solche Codecs auch ganz vorne benutzt werden denn meistens relativieren sich solche Vorteile, wenn bereits ein anderer Codec vorgelagert wurde.
Man muss also immer beide Codecs im Verhältnis zueinander sehen, um die Auswirkung der Kombination abschätzen zu können.

@Jörg
Das bezieht sich auch auf den von Dir angewandten Codec.
Der Codec allein erfüllt bestimmte Parameter.
In Verbindung mit einem andern Vorcodec können aber völlig andere Ergebnisse dabei herauskommen.

Daher auch immer wieder der Hinweis, wenn möglich im Originalcodec bis zum Endprodukt zu bleiben.
Ob nun Fehler -mehr oder weniger- sichtbar sind, stellt sich sowieso erst auf dem TV des Zuschauers heraus und nur selten auf dem Monitor des NLEs, nur können wir solchen Fehlern nur dadurch entgegenwirken, dass wir alles vermeiden, was und zusätzliche Mängel in der Kette generiert.
Und ein Mangel ... das steht glaube ich außer Frage und das wird wohl auch hier als Konsenz gehandelt, ist, dass Transkodierungen mit absoluter Sicherheit mit Nachteilen behaftet sind und wenn es irgendwie zu vermeiden ist, auch vermieden werden sollte.
Und wenn die Rechnerkapazität nicht wirklich ausreicht, man wenigstens einen Intermeditat Codec nutzt, der in der Entwicklung auf dem Stand ist, den der Akquisitionscodec hat.
Also irgend ein AVC -I Frame only. Damit ist man (heutzutage) immer am dichtesten am Original. Kommt nun drauf an, welcher Codec im NLE implementiert ist, also arbeitsfähig und nicht nur im Player zum Import.

WoWu hat geschrieben:... und das wird wohl auch hier als Konsenz gehandelt, ist, dass Transkodierungen mit absoluter Sicherheit mit Nachteilen behaftet sind und wenn es irgendwie zu vermeiden ist, auch vermieden werden sollte.
Und wenn die Rechnerkapazität nicht wirklich ausreicht, man wenigstens einen Intermeditat Codec nutzt, der in der Entwicklung auf dem Stand ist, den der Akquisitionscodec hat.

Es ist zu hoffen, dass diese klare Ansage dazu führt, dass der hier so sehr verbreitete Transkodierungswahn zumindest etwas gebremst wird. Denn manchmal bekommt man hier den Eindruck, dass irgendeine Transkodierung einfach zum guten Ton gehört und ohne eine solche gar nicht gearbeitet werden könnte. 4K in Raw oder Mega-Motion-Design klappt eben nicht mit einem Billig-Rechner. Das ist zwar völlig trivial, scheint aber trotzdem der Phantasie keine Grenzen zu setzen, so dass selbst bei einfachsten Full-HD-Projekten wahre Klimmzüge für Transkodierungen gemacht werden.

Denn manchmal bekommt man hier den Eindruck, dass irgendeine Transkodierung einfach zum guten Ton gehört

da bist Du aber fast der Einzige der das so sieht.
Die Meisten sehen das als Alternative wenns denn mal sein muss.

@WoWu
Klar, Transformationsverluste gibt es immer, muss es geben.
Wenn ich aber einen Intermediate verwende, dann mach ich das hauptsächlich aus Performancegründen. Und das bedeutet Vereinfachung, immer, denn sonst würde sich nicht die Performance verbessern.
Und da bin ich der Meinung, dass bei der Überführung komplexer Algorithmen in einfache die Qualität durch höhere Datenrate beibehalten wird.

Aber man hat ja immer mehrere Möglichkeiten ;)
Da wäre als nächstes zu klären, ob ein AVC-Intra, den ich ja auch verwenden kann (und der schon mal Performance-Gewinn gegenüber einem GOP-basiertem Codec bringt) genauso stabil über mehrere Generationen hinweg ist, wie z.B. DNxHD. Dass GOP-basierte Codecs das nicht sind, ist ja Konsens, oder.

TomStg hat geschrieben:

WoWu hat geschrieben:... und das wird wohl auch hier als Konsenz gehandelt, ist, dass Transkodierungen mit absoluter Sicherheit mit Nachteilen behaftet sind und wenn es irgendwie zu vermeiden ist, auch vermieden werden sollte.
Und wenn die Rechnerkapazität nicht wirklich ausreicht, man wenigstens einen Intermeditat Codec nutzt, der in der Entwicklung auf dem Stand ist, den der Akquisitionscodec hat.

Es ist zu hoffen, dass diese klare Ansage dazu führt, dass der hier so sehr verbreitete Transkodierungswahn zumindest etwas gebremst wird. Denn manchmal bekommt man hier den Eindruck, dass irgendeine Transkodierung einfach zum guten Ton gehört und ohne eine solche gar nicht gearbeitet werden könnte. 4K in Raw oder Mega-Motion-Design klappt eben nicht mit einem Billig-Rechner. Das ist zwar völlig trivial, scheint aber trotzdem der Phantasie keine Grenzen zu setzen, so dass selbst bei einfachsten Full-HD-Projekten wahre Klimmzüge für Transkodierungen gemacht werden.

Das scheint mir auch manchmal so. Da bist Du in der Annahme nicht ganz so allein.

dienstag_01 hat geschrieben:@WoWu
Klar, Transformationsverluste gibt es immer, muss es geben.
Wenn ich aber einen Intermediate verwende, dann mach ich das hauptsächlich aus Performancegründen. Und das bedeutet Vereinfachung, immer, denn sonst würde sich nicht die Performance verbessern.
Und da bin ich der Meinung, dass bei der Überführung komplexer Algorithmen in einfache die Qualität durch höhere Datenrate beibehalten wird.

Aber man hat ja immer mehrere Möglichkeiten ;)
Da wäre als nächstes zu klären, ob ein AVC-Intra, den ich ja auch verwenden kann (und der schon mal Performance-Gewinn gegenüber einem GOP-basiertem Codec bringt) genauso stabil über mehrere Generationen hinweg ist, wie z.B. DNxHD. Dass GOP-basierte Codecs das nicht sind, ist ja Konsens, oder.

Nein, das ist nicht so ganz richtig, denn bei schlichten MPEG2 gab es eigentlich keine Notwendigkeit, weil die Ergebnisse auch eher holzschnittartig waren. Der Leistungsbedarf entstand erst mit ausgefeilteren Algprithmen und anderer Anforderung an die Architektur.
Aber man darf den Cpdec nicht für die Schwäche der Rechner und der Software verantwortlich machen.
Es gibt nun mal die Balance zwischen Echtzeitanforderung und Rechnerleistung und entweder entscheidet man sich für einen guten Codec und muss, wenn man die Echtzeitfähigkeit nutzen möchte, am Rechner drehen, oder man entscheidet sich für einen schwachen Rechner und muss an der Echtzeitfähigkeit drehen ... oder eben, die Ergebnisleistung reduzieren und auf einen schwächeren Codec zurückgreifen.
Jeder nach seiner Wahl und seinen Möglichleiten.
Insofern besteht durchaus keine Notwendigkeit der Transcodierung, da gebe ich Tom völlig Recht.

Und was die Stabilität betrifft, solange Du nicht 50 oder mehr Kopien machst, halten GOP basierte Codecs durchaus mit und ob das nun 2 oder 3 dB weniger Störabstand sind, .... da mag man nun streiten, ob man das sieht.

WoWu hat geschrieben:Nein, das ist nicht so ganz richtig, denn bei schlichten MPEG2 gab es eigentlich keine Notwendigkeit, weil die Ergebnisse auch eher holzschnittartig waren. Der Leistungsbedarf entstand erst mit ausgefeilteren Algprithmen und anderer Anforderung an die Architektur.
Aber man darf den Cpdec nicht für die Schwäche der Rechner und der Software verantwortlich machen.
Es gibt nun mal die Balance zwischen Echtzeitanforderung und Rechnerleistung und entweder entscheidet man sich für einen guten Codec und muss, wenn man die Echtzeitfähigkeit nutzen möchte, am Rechner drehen, oder man entscheidet sich für einen schwachen Rechner und muss an der Echtzeitfähigkeit drehen ... oder eben, die Ergebnisleistung reduzieren und auf einen schwächeren Codec zurückgreifen.
Jeder nach seiner Wahl und seinen Möglichleiten.
Insofern besteht durchaus keine Notwendigkeit der Transcodierung, da gebe ich Tom völlig Recht.

Ja, mach dirs mal schön einfach ;)
Avid z.B. bietet mir nur die Möglichkeit, zur Weiterverarbeitung (Encoding) über DNxHD rauszugehen (Ich kann noch Quicktime h264 mit Keyframe jedes Bild wählen, damit hab ich aber noch keine Erfahrung - und neuerdings geht auch DNxHR, fehlt mir ebenfalls die Erfahrung). Ich MUSS also in DNxHD wandeln - wenn ich nicht direkt zum TV will (da geht auch anderes).
Hat also nichts mit dieser simplen Gleichung Performance vs Qualität zu tun.
Der Beitrag hat auch sonst eher alle Fragen offen gelassen ;)

imho wäre es wohl sinnvoller den intermediate durch einen proxy zu ersetzen und final das original auszuspielen.

btw. ich schliesse mich der meinung von tomstg und wowu an, daß wird hier nicht immer gänzlich verstanden.

lg

srone

ich schliesse mich der meinung von tomstg und wowu an, daß wird hier nicht immer gänzlich verstanden.

Also VERSTEHEN tut man das schon, dass du derselben Meinung bist. Nur interessiert das hier nicht, es geht nämlich nicht um Meinungen, hier wird nicht abgestimmt. Wenn du es mit Fakten versuchen würdest... ;)

wenn die fakten, der nicht zitierte teil meines posts, derart übergangen werden, frage ich mich was du eigentlich willst, ausser trollen?

lg

srone

wenn die fakten, der nicht zitierte teil meines posts,

Der Teil ist nicht zitierFÄHIG, oder hast du jetzt Ahnung von Avid ;)
(und komm jetzt nicht mit Resolve)

Hier gings ja eigentlich um Fakten zur Umwandlung und nicht darum, welcher Workflow besser oder schlechter ist. Aber klar, für Leute die dazu nichts zu sagen haben, aber trotzdem ihren Quark dazu geben möchten, bitte weiter ;)

Ansonsten würde mich weiter interessieren, wieso eine Dekodierung bist zu Einzelbild bei der Anzeige fehlerfreier sein soll, als eine Dekodierung bis zum Einzelbild zur Umwandlung mit nachfolgender Neukodierung in einen anderen Codec.

Weil das Bild bei der zweiten Codierung mit einem weniger präzisen Codec geschieht und damit eine schlechtere Qualität aufweist als das Bild mit der Ursprungscodierung.

WoWu hat geschrieben:Weil das Bild bei der zweiten Codierung mit einem weniger präzisen Codec geschieht und damit eine schlechtere Qualität aufweist als das Bild mit der Ursprungscodierung.

damit ist wohl alles gesagt.

lg

srone

WoWu hat geschrieben:Weil das Bild bei der zweiten Codierung mit einem weniger präzisen Codec geschieht und damit eine schlechtere Qualität aufweist als das Bild mit der Ursprungscodierung.

Wenn du sagst, dass der Codec weniger präzise als h264 ist, ist das ja eine generelle Aussage über den Codec. Gilt allgemein. Auch für Kameras, die mit diesem Codec aufzeichnen. Wie z.B. eine Alexa.
???

Dann geht es letztlich gar nicht um die Umkodierung, sondern um den Codec an sich, der nicht gut ist?

Ein Intermediate Codec ist IMHO immer unkomprimiert (oder wenigstens lossless), alles andere ist ein fauler Kompromiss mit Verschlimmbesserung.

Das nächst beste ist Cineform. Log GOP geht eigentlich gar nicht bei der Aufzeichnung und als Intermediate.

Wir reden hier speziell von DNxHD.

Ein Intermediate Codec ist IMHO immer unkomprimiert

der Canopus HQ [HQX] zum Bsp.kann die Komprimierung steuern,maximal ist 2:1.
Lossless wäre der Canopus lossless.

Wir reden hier speziell von DNxHD.

aber erst in den letzten paar Beiträgen.
Ich habe mich noch gar nicht grossartig mit dem befasst.

Gibt's ja auch erst seit 11 Jahren ...

"Das Institut für Rundfunktechnik (IRT) hat den DNxHD-Codec neben weiteren Codecs (AVC-Intra, Apple ProRes, HDCAM SR) für den Einsatz bei hochauflösenden Premium-Produktionen von ARD, ZDF, ORF und SRG zugelassen und bescheinigt ihm selbst bei niederen Datenraten ein gutes Multigenerationsverhalten."

Da sind ja alle minderwertigen Codecs versammelt bei den Premium-Produktionen! :-)

dienstag schreibt

oder hast du jetzt Ahnung von Avid ;)

seitwann muss man denn Ahnung von Programmen haben, um hier Unsinn zu schreiben???
Das beweist du doch mit tausenden Beiträgen zu Premiere, von dem du ja auch null Ahnung hast ;-((

srone schreibt

damit ist wohl alles gesagt.

für die meisten schon, aber dann kommen die Wochentage.

@Goldwingfahrer
DNxHD soll hier für eine bestimmte Art der Intermediate Codecs stehen. ProRes ist m.W. ja ähnlich, Canopus kenne ich nicht.

WoWu ist in seiner Aussage/Ablehnung je generell gegen diese Art von Codecs, man muss das mit der Beschränkung auf DNxHD nicht so auf die Goldwaage legen. Es geht aber definitiv nicht um Lossless Codecs.

Doch, es geht zunächst einmal NUR (generell) um Codecs, denn, egal ob MPEG 2 oder irgendein MPEG4, findet zunächst einmal (um bei den hier verwendeten Beispielen zu bleiben), die Überführung in Makroblöcke statt.
Dabei ist es eben auch egal, ob es sich bei dem nachgelagerten Übertragungsverfahren, um ein I-Frame Format handelt, oder ob nur der Fehler zwischen den Bildern übertragen wird. In einem I-Frame Verfahren, steckt der Fehler dann eben in jedem Bild und die Datenmenge wird allgemein größer, in einem GOP Verfahren werden dann eben nur die Fehler (in kleiner Datenmenge) übertragen, und das restliche, unveränderte Bild wird dann aus dem Speicher genommen und mit dem Fehlersignal zu einem Gesamtbild verrechnet.
Es ist also mehr Rechenaufwand erforderlich.
Wer also GOP (geht gar nicht) mit Bildqualität verwechselt, hat die Funktion noch nicht begriffen.
Die Qualität hängt nämlich davon ab, welche Tools ich verwende. Und wenn meine Akquisitionstools eine bestimmte Güte (in verschiedenen Hinsichten) haben, und meine Intermeditae Tools dahinter zurück bleiben, ist mein Bild nach der Transkodierung nur noch so gut, wie das schlechteste Tool in der Kette und wenn ich meine Bewegungen in der Alquisition sehr präzise auflöse, und im Folgecodec nur noch mit weniger Präzision, dann ist mein Bild nur noch so gut. wie die neue Codierung es zulässt, anzüglich evtl bereits verminderter Qualitätsdifferenzen aus der Ursprungskodierung.
Diese Differenzen fallen weg, wenn ich gleich den Intermediate Codec als Akquisitionscodec verwende, aber auch die Vorteile besserer Tools. Dann hat man gleich die schlechtere Encodingqualität, aber immernoch besser als die, nach einer Transcodierung.
Man muss mal aufhören, nur mit Schlagworten (GOP, Lossöess, usw.) zu argumentieren, weil sie wenig mit dem hier eigentlich Diskutiertem zu tun haben, zumal solche Bezeichnungen wie Lossless viel zu relativ sind ... denn deren Definition ist viel zu wenig definiert.
In diesem Thread geht es ja darum, ob eine Transcodierung mit Nachteilen behaftet ist ... oder nicht und da spielen ausschließlich die verwendeten Codier und Reduktionsverfahren eine Rolle und welche Bildanteiöe bei welchem Verfahren verloren gehen, bzw. bereitsverloren sind denn auch ein Lossless Codec ist nur dann Lossless, wenn er auf ein analoges Bild zugreifen kann und der Verlust nicht schon im Vorcodec entstanden ist.
Dann ist auch Lossless ziemlich unnütz.

Servus WoWu!
Wenn wir also in der jeweiligen Kette, die Rechenleistung und die
sagen wir Kompressionsgrösse, stärke senken ( schnelle Chips, Software,
ssd, Speicher kosten nun auch nur noch einen Sch()..) dann würden wir da
ja schön am Rad drehen. Bevor aber die Hersteller das tun ( oder abhängig von Preisgruppen und Einsatzderivaten) wird auf des schöne Maultier 8k ge
setzt, also wäre der Zugewinn an all dem neuen schnellen ( in der Holzklasse, 2.te Klasse mal also wir oft, im realen Investleben) Dingen, wieder nur da stehen bleiben müssen, wo wir eh schon waren.
Außerdem, stell Dir vor, da ist einer der ist zu gut!
Wie kann der nur, und was hätte es für Marktauswirkungen?
Wobei, so tranquil sie sind, des Smartphone schleicht sich dem Körper ( des jeweiligen Vorstandes/Techdepartements) hoch.. und jetz lötens und forschens halt mit Wasser bis zur Arschkante.. Noch brennen die Kessel, noch spielt die Band..noch.
Noch leistet sich Sony zb drei unabhängige Departements.. was ja toll aber auch wahnsinnig ist, Der Mann mit den drei Füßen halt... :)

Der arme Threadstarter.

Fassen wir mal zusammen: Editing via Intermediate Codec ist überall üblich, vom simplen Webfilmchen bis hin zu Hochglanzwerbung und Hollywood. Die meisten üblichen verdächtigen NLEs haben dazu eine bewährte Bordlösung:

AVID - DNxHD
Edius - Canopus
fcp - ProRes

Nur Adobe hat nichts Eigenes, da muss man selber schauen, wo man bleibt.

ProRes dürfte mit Abstand am verbreitetsten sein, ist längst aus fcp herausgewachsen und wird inzwischen auch von allen professionellen Kameraherstellern als Akquisitionscodec angeboten. Gefolgt von DNxHD, das sich ebenfalls in diversen Kameras findet.

Es ist auch Konsens, dass es sehr viel Sinn macht, wackelige Long GoP-Kameracodecs wie AVCHD zu ProRes und Konsorten zu überführen, bevor man mit der heute wohl unerlässlichen Effekt- und Gradingorgie loslegt.

Außerdem verschwimmen die Bezeichnungen: ProRes und DNxHD sind inzwischen gar keine Intermediates mehr, sondern auch als Mastercodecs üblich. adstream zum Beispiel, europaweit führendes Upload-Portal für TV-Content, verlangt vorzugsweise ProRes.

Nun gibt es da den wowu, der seit vielen Jahren unermüdlich mit den immer gleichen Sätzen gegen ProRes kämpft (gegen das exakt gleich angelegte DNxHD von AVID komischerweise nicht, ein Versäumnis). Früher waren es die angeblich weichen Bilder wegen Wavelet, die ihn virtuell aufgeregt hatten, dann hat er den Irrtum irgendwann bemerkt und wettert jetzt wegen angeblich riesiger Makroblöcke wie bei MPEG 2. Beides konnte er natürlich nie zeigen, auch andere sehen so was nicht - dabei müssten die bösen Artefakte doch überall, auch in TV und Kino, ständig präsent sein, allein schon wegen der Alexa.

Egal. wowu plädiert vehement für irgend einen Intracodec auf AVC-Basis statt ProRes oder DNxHD, wenn der Kameracodec H.264-basiert war.

Wer schneidet mit AVC Intra oder XAVC Intra als Intermediate Codec? Hand hoch und berichten!

Ich, AVC Intra, kommt so aus der Kamera. Damit komme ich aber nicht so ohne weiteres aus dem Avid.

Wo ist eigentlich die von Panasonic schon lange angekündigte neue AVC Ultra-Codecfamilie abgeblieben? In der Panasonic seinen alten AVC Intra 100 nur noch im unteren Mittelfeld sieht.

Jott hat geschrieben:Fassen wir mal zusammen: Editing via Intermediate Codec ist überall üblich, vom simplen Webfilmchen bis hin zu Hochglanzwerbung und Hollywood. Die meisten üblichen verdächtigen NLEs haben dazu eine bewährte Bordlösung:

AVID - DNxHD
Edius - Canopus
fcp - ProRes

Nur Adobe hat nichts Eigenes, da muss man selber schauen, wo man bleibt...

Wer schneidet mit AVC Intra oder XAVC Intra als Intermediate Codec? Hand hoch und berichten!

Ich bleibe bei Premiere CC2015 einfach dort, wo man sein sollte, um Zeit zu sparen und Fehler zu vermeiden: nativ mit XAVC Intra auf der Timeline - kommt so aus meiner FS7.

Du begibst Dich auf ziemliches Glatteis, indem Du einen Workflow postulierst, bei dem Intermediate Codecs stets üblich und Adobe-Anwender arme Schweine seien. Das mag zutreffen bei nicht-performanter Hard-/Software, aber nicht bei aktueller Ausstattung. Bei mir gehen AVCHD, XAVC Long und besonders XAVC Intra jedenfalls sehr schnell und sehr easy auf der Timeline - ohne irgendein Transcodierungsgefummel.

Mir scheint, dass Deine Ausführungen eher vom Motto "Haben wir schon immer so gemacht." geprägt sind und weniger von der Akzeptanz, dass es heutzutage auch wesentlich besser gehen kann - dh einfacher, sicherer, schneller und ohne zusätzliche Qualitätsverluste.