Premiere auf dem MAC - Editing-Codec Prores oder DNxHD

[Kamerafreund]

Hi,
ich würde auf dem Macbook Pro (2012) gerne das 50p XAVC-S-Material der Sony A7s bearbeiten. Damit Farbkorrektur und Effekte etwas schneller gehen, würde ich gerne in einen Editing-Codec transcodieren. Ist da Prores oder DNxHD besser?

Soweit ich gehört habe:

Prores soll auf dem Mac gelegentlich schneller laufen, arbeitet aber in 32bit-Umgebung - also wieder langsamer?

Prores gibt es nur in 10bit (richtig?) - ich würde also bei gleicher Datenrate beim Transcodieren meiner XAVC-S 8Bit Files weniger Details haben?

Hat jemand Erfahrung mit beiden Codecs?
Danke!

[Peppermintpost]

dnxhd ist einen hauch schneller. aber prores läuft auch super. ich finde der performance unterschied ist so klein, das man das vergessen kann. was ich wichtig finde ist farb konsistenz. dnxhd ist grundsätzlich natürlich genau so konsistent wie prores ABER dnxhd gibt dir die möglichkeit verschiedene farbräume auszuwählen, damit kommt es schnell zu einem farbschift, der ist natürlich durch falsche bedienung verursacht, ist aber in der praxis ja egal wo er her kommt. bei prores hast du das problem nicht. entscheide dich ob du proresHQ oder prores4444 benutzen willst und alles ist gut. du brauchst einfach nicht mehr drüber nachdenken.

[Kamerafreund]

Danke!
Verschenke ich denn nicht ziemlich viel Bandbreite, wenn ich 8Bit Material auf 10Bit hochrechne? Und dazu noch 420 auf 444 :O
Kann ich den Farbraum von DNxHD im AME einstellen?

[mash_gh4]

ABER dnxhd gibt dir die möglichkeit verschiedene farbräume auszuwählen, damit kommt es schnell zu einem farbschift, der ist natürlich durch falsche bedienung verursacht, ist aber in der praxis ja egal wo er her kommt. bei prores hast du das problem nicht. entscheide dich ob du proresHQ oder prores4444 benutzen willst und alles ist gut. du brauchst einfach nicht mehr drüber nachdenken.

ich würde mich zwar deiner meinung anschließen, was die perfomance betrifft, kann aber leider nicht ganz unterschreiben, was du bezüglich der farbräume und data-ranges proklamierst.

obwohl es zwar am mac ziemlich wenig diesbezügliche probleme mit prores gibt, da sich alle programme der selben systembestandteile bei der umsetzung bedienen, ist das leider auf anderen betriebssystemen nicht der fall. prores ist in dieser hinsicht insofern problemtisch, als man es nur in quicktime containern verwenden kann, die leider kein verbindliches flag besitzten, um anzuzeigen, ob full-range oder legal-range verwendet wird. der einzige anhaltspunkt dafür ist die art und weise, wie das apple programme bzw. alle software, die sich der quicktime schnittstellen bedient, handhaben. konkret verwendet nämlich proress444 RGB normalerweise full-range, während es bei den älteren XCbCr basierenden varianten immer legal-range sein sollte. bei DNxHR gibt es diese fehlerquelle nicht, da tatsäch immer nur letzteres benutzt wird.

auch in puncto farbräume gibt es leider ganz ähnliche probleme. defaultmäßig nutzt prores unterhalb der 444-varianten, unabhängig von der auflösung, uralte historische farbmodelle, die im HD umfeld überhaupt keinen sinn mehr ergeben. erst durch die einbettung von zusätzlichen angaben über den genutzten farbraum im datenstrom wird das dahingehend abgeändert, dass es sich auf die heute üblichen rec709 videostandards bezieht. genau dieser angaben werden allerdings von verschiedenen programmen unterschiedlich behandelt. in der praxis ergeben sich daraus leider immer wieder ziemliche kompatibilitätsprobleme.

prores444 RGB ist natürlich in dieser hinsicht ein grenzfall, der sich hier zwar ein wenig unproblematischer verhält, aber leider auf grund der doch sehr hohen datenrate wieder andere nachteile mit sich bringt. das kann sich auch in der praxis spürbar negativ auswirken.

und weil es hier immer wieder ganz explizit gefragt wird:
wenn in in diesen 10bit formaten nur 8bit genutzt werden -- die am wenigstens signifikanten binär stellen also einfach mit nullen gefüllt werden --. macht das keinen nennenswerten unterschied. es wird dadurch nur ein bisserl platz bzw. potentiell nutzbare übertragungsbandbreite verschenkt bzw. verschwendet, sonst hat es keine nennenswerten folgen.

[Peppermintpost]

flame, nuke, after effects, premiere, avid und resolve hab ich mit proresHQ durch getestet, auf mac und pc. kein farbshift. wer natürlich proresHQ und prores4444 mischt darf sich nicht wundern wenn was unterschiedliches dabei heraus kommt das ist ja klar, da steht ja schon im namen ACHTUNG ANDERER FARBRAUM!!! das andere programme das anders interpretieren ist möglich, aber ich denke die oben beschriebenen decken schon das ab was standart in der prof. postpro welt ist. alles andere ist mir auch egal.

[mash_gh4]

flame, nuke, after effects, premiere, avid und resolve hab ich mit proresHQ durch getestet, auf mac und pc. kein farbshift. wer natürlich proresHQ und prores4444 mischt darf sich nicht wundern wenn was unterschiedliches dabei heraus kommt das ist ja klar, da steht ja schon im namen ACHTUNG ANDERER FARBRAUM!!! das andere programme das anders interpretieren ist möglich, aber ich denke die oben beschriebenen decken schon das ab was standart in der prof. postpro welt ist. alles andere ist mir auch egal.

ganz konkret kenne ich diese probleme speziell von resolve, wo die entsprechenden sorgen einen großteil des firmeneigenen forums, aber auch spezialisierterer diskussionsplattformen, wie lift gamma gain, füllen.

in diesem programm hat man z.b. erst unlängst plötzlich die defaultwerte für die genutzten levels und die berücksichtigung manueller angaben beim prores444 export ohne große vorankündigung od. erklärungen abgeändert bzw. korrigiert:

https://forum.blackmagicdesign.com/view ... 21&t=56241

derartiges macht die sache nicht unbedingt transparenter oder einfacher für normalsterbliche nutzer. es mag aber auch sein, dass ich vor allem deshab bei derartigen problemen sofort an resolve denken muss, weil man sich ja dort beharrlich weigert, mpeg4 als exportcontainer für ganz gewöhnliche h.264 ausgaben anzubieten, was zur folge hat, dass alle auf .mov ausweichen müssen, wo eben genau dieses flag fehlt, das den genutzten wertebereich anzeigen würde. deshalb gibt's andauernd probleme mit den resultaten. :(

aber natürlich gebe ich dir vollkommen recht, dass man im professionellen umfeld, aber auch im eignen arbeiten, gewöhnlich kaum mit diesen sorgen und detailproblemen konfrontiert wird. in dem meisten fällen klappt es ohnehin ganz reibungslos. und wenn es einnmal nicht passt, ist der grund für entsprechend eingeweihte meist ohnehin derart offensichtlich, dass es auch wieder mit einem handgriff schnell korrigiert ist.

trotzdem: völlig verklären oder wegdiskutieren sollte man diese potentiellen stolpersteine nicht. jeder muss selbst einmal damit zu kämpfen gehabt haben und eine gewisse sensibilität dafür entwickeln, um entsprechende komplikationen konsequent zu meiden.

[dienstag_01]

Aus dem Grund, dass der TO explizit von DNxHD (und nicht HR) spricht, kann ich nur sagen, dessen Verwendung kann beim Austausch mit anderen Programmen auch zu Fehlinterpretationen führen. Die Luma Range und die verschiedenen Bearbeitungsprogramme sind (und bleiben sicher noch eine Weile) unsere zarten Kätzchen, die gehätschelt werden wollen ;)