Newsmeldung von slashCAM:Ab sofort kann das (eigentlich schon für Ende Februar angekündigte) Firmware Update 6.2 für den mobilen Recorder /Monitor Atomos Shogun runtergeladen werden. Es bringt 3D LUTs, Avid DNxHR und DNxHD Aufnahme, 4K nach HD Downscaling auf dem Loop Out Ausgang, ein Vorschaubild bei der Wiedergabe sowie eine größere Audioanzeige.
zur News
Antwort von klusterdegenerierung:
Da habe ich ja garnicht drüber nach gedacht, das ich den DNxHR Codec in PP nicht nutzen kann.
Gibt es da jetzt wirklich nur den Weg sich Media Composer zu zulegen, oder gibt es den als Codec zu kaufen etc. ?
Witzig, alle freuen sich wie ein Schneekönig, aber kaum einer hat MC.
Und watt nu? :-(
Antwort von Jott:
ProRes? ;-)
Antwort von DV_Chris:
Aktuelles Avid Codec Pack installieren:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... .0_Win.zip
Antwort von klusterdegenerierung:
Aktuelles Avid Codec Pack installieren:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... .0_Win.zip
Probiere ich gleich mal aus, Danke!
Antwort von marwie:
Aktuelles Avid Codec Pack installieren:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... .0_Win.zip
Super, funktioniert zumindest mit Premiere Pro CS6 :-) Wie hast du die Version 2.6.0 gefunden? wenn man danach sucht, findet man nichts und im Download Center ist die Version 2.5 die neuste...
Antwort von CameraRick:
Aktuelles Avid Codec Pack installieren:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... .0_Win.zip
Wow, gibts die jetzt auch so für andere Systeme? Das ist groß.
Wie marwie schon schrieb kann man auf Google die 2.6 nicht so recht finden. Haste zufällig auch einen Link für Mac? Bin noch auf der Arbeit :(
Antwort von -paleface-:
Gibt es denn inzwischen irgendwo einen guten Verleich zwsichen dem ProRes und DNxHR Codec?
Bisher kenne ich nur die Meinung: Prores ist besser. Punkt.
Aber höre mir gerne was anderes an.
Antwort von CameraRick:
Ich habs mal im DaVinci vergleichen, natürlich nicht wissenschaftlich, und da ist mein Eindruck wie vorher bei DNxHD: sie sind ziemlich gleich (*). DaVinci bietet (mir) aber auch nicht die optimale Grundlage, daher hätte ich es gern für Mac dann kann ichs hier auch gescheit testen (oder erst heut Abend daheim auf Win)
Verhalten sich im Grunde ähnlich, der richtige Unterschied lag nur im unteresten Detail
(*)
Verglichen habe ich jetzt im Endeffekt nur die 10bit Varianten, sprich 422HQ mit dem entsprechenden Avid; die kleinen Avid-Äquivalente (also die zu 422, LT, Proxy) sind eben weiterhin nur 8bit und damit (für mich) uninteressant, ich habe ohnehin keine Verwendung für die kleineren Formate (bzw wenn, zB als Proxys, ist mir Lachs ob 8 oder 10bit).
DNxHR 444 ist weiterhin größer als Prores 4444 aber auch nur 10bit statt 12, einen gravierenden Unterschied durch die 2bit konnte ich nicht ausmachen; DNxHR scheint mir manchmal etwas weniger Artefakte zu haben, aber das hab ich nicht mehr so ganz auf dem Schirm. PR4444 QX habe ich nicht angeschaut.
Quellmaterial war Arriraw.
Mir selbst ist Prores noch a bissl lieber, aber das kann auch einfach die Gewohnheit sein. Sofern DNxHR jetzt auch in anderer Software (als nur DaVinci und AMC) funktioniert wäre es aber eine ziemlich tolle Geschichte, meiner Meinung nach.
Egal wie gut Cineform auch sein mag, so richtig warm werde ich damit nicht.
Antwort von DV_Chris:
Als Händler hat man seine Quellen ;-)
Antwort von CameraRick:
Als Händler hat man seine Quellen ;-)
Und diese darf man dann teilen? :) Danke dafür auf jeden Fall, heut Abend schau ich mir das daheim mal an.
Antwort von DV_Chris:
Hier das Codec Pack für Mac:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... ac.pkg.zip
Antwort von DV_Chris:
Als Händler hat man seine Quellen ;-)
Und diese darf man dann teilen? :) Danke dafür auf jeden Fall, heut Abend schau ich mir das daheim mal an.
Ich stehe nicht unter NDA und die Quelle ist seriös.
Antwort von CameraRick:
Ach die Quelle würde ich gar nicht anzweifeln, war mehr nur ein Spaß :)
Danke Dir ganz herzlich für die Codecs, bin für heute quasi durch und checke das mal gegen :)
Antwort von CameraRick:
Habs mal angeschaut... aber so recht klappt das noch nicht, da muss man noch einmal ran.
-Die 10bit und 8bit Varianten (jeweils die größte, keine Ahnung bei den Proxys) haben, egal was ich einstelle, ein deutliches Gamma-Problem
-AE importiert keine MXF DNxHR aus DaVinci
-DaVinci importiert keine MOV DNxHR aus AE
-Probleme herrschen auf Mac und PC
422 10bit is leicht größer als Prores 422 HQ, 444 ist deutlich größer als Prores 4444
Die 444 Modelle kann man ganz gut vergleichen. DNxHR schneidet leicht schlechter ab, enkodiert aber schneller (in AE).
Müsste das noch einmal mit Miraizon vergleichen...
Antwort von wolfgang:
Also bei DNxHR habe ich auf die Schnelle in Vegas mal kein Gamma Problem gesehen. In Vegas kann DNxHR problemlos importiert werden, auch in Edius.
Antwort von CameraRick:
Womit hast Du es enkodiert?
Ich hab jetzt alles von Adobe Software aus getestet. Kannst Du im Edius oder Vegas die DNxHR MXF aus DaVinci einladen?
Der Gamma-Shift bei 422 Material ist schon recht deutlich:
http://i.imgur.com/uSkoj5y.jpg
Antwort von dienstag_01:
Schon mal irgendwas mit einem der Avid Codecs zu tun gehabt? Oder muss man hier bei Null anfangen?
Antwort von merlinmage:
Da kommt der dienstag wieder raus. Hi! :)
Antwort von wolfgang:
Womit hast Du es enkodiert?
Ich hab jetzt alles von Adobe Software aus getestet. Kannst Du im Edius oder Vegas die DNxHR MXF aus DaVinci einladen?
Der Gamma-Shift bei 422 Material ist schon recht deutlich:
http://i.imgur.com/uSkoj5y.jpg
Ich bezweifle nicht dass dies bei dir auftritt. Das kann in verschiedenen Werkzeugdn halt unterschiedlich sein. Aufgezeichnetes DNxHR zeigt nach dem Import in Vegas mit der GH4 erstellte Testbalken (ARIB etwa) mit korrekter Luma und korrekte Farben an. Dekodierte wird mit dem hier verlinkten codec-package.
Antwort von CameraRick:
Schon mal irgendwas mit einem der Avid Codecs zu tun gehabt? Oder muss man hier bei Null anfangen?
Ach "ein wenig", aber fang ruhig bei 0 an ich komm dann nachher dazu.
Ich bezweifle nicht dass dies bei dir auftritt. Das kann in verschiedenen Werkzeugdn halt unterschiedlich sein. Aufgezeichnetes DNxHR zeigt nach dem Import in Vegas mit der GH4 erstellte Testbalken (ARIB etwa) mit korrekter Luma und korrekte Farben an. Dekodierte wird mit dem hier verlinkten codec-package.
Achso, Du nimmst natives Material, vermutlich aus Deinem Shogun?
Ich meine speziell jetzt nur Codecs, die via dem Codec-Package auch enkodiert wurden. Die DNxHR 422 (ich hab keine Ahnung wie der richtig heißt, ihr wisst schon was ich meine) aus DaVinci weisen auch keinen Shift auf, sehr wohl aber die aus AE und co. Ich versuchs gleich mal mit dem Nuke.
Antwort von dienstag_01:
Ach "ein wenig", aber fang ruhig bei 0 an ich komm dann nachher dazu.
Sehr gut ;)
AE importiert keine MXF DNxHR aus DaVinci
Fakt Nummer 1: Adobe konnte noch nie Avid Files im mxf-Container lesen.
EDIT: das ist falsch, spätestens mit CC geht es, hab ich gerade mitbekommen, so als Spätmerker ;)
Das könnte sich natürlich irgendwann mal ändern. Aber das muss Adobe machen, Avid wird sicher sein Containerformat nicht für seine eigenen Apllikationen *unleserlich* machen, damit es in Adobe funktioniert.
Ich gebe zu, der letzte Teil ist eine Vermutung, sozusagen Vermutung Nummer 1 ;)
Antwort von CameraRick:
Fakt Nummer 1: Adobe konnte noch nie Avid Files im mxf-Container lesen.
Siehe Anhang
So oder so war das mehr eine Feststellung, keine versteckte Frage warum das nicht geht. Spannend finde ich jedoch dass DaVinci (noch) keine MOV DNxHR liest. Kommt vermutlich im nächsten Update dabei.
Antwort von dienstag_01:
Siehe Anhang
Und was heisst das jetzt?
Antwort von CameraRick:
Das ist eine MXF in DNxHD36 aus dem Avid, die man in Adobe ja nicht lesen kann, importiert in AE
Antwort von dienstag_01:
Stimmt, geht, mit AE CC.
Ändere ich oben ab.
Fakt Nummer 2: Gammashift
Es gibt zwei Farbraumoptionen für DNxHD im Mov-Container (und auch für DNxHR), 709 und RGB.
Adobe hat es in einer Meisterleistung hinbekommen (andere Hersteller von NLEs haben sich dem angeschlossen), nur die RGB Variante *richtig* zu importieren, die 709 Variante wirkt *ausgewaschen*, da die Full Range auf Legal Range abgebildet wird. Muss man wissen.
Dumm dabei ist, dass die RGB-Variante alles unterhalb von 16 und oberhalb von 235 abschneidet. Für Broadcast normal, wenn man aber mit den Einstellmöglichkeiten bspw. einer GH4 spielt (und das File vor dem Import in Adobe wandelt), sollte man das nicht vergessen ;)
Antwort von CameraRick:
Das ist witzig, weil sowohl 709 als auch RGB den Gammashift aufweisen, oder denkste ich porbier nur eine Option aus? :o)
Bei DNxHD ist das übrigens nicht so aufgetreten.
Dass RGB (entgegen dem, was man gerne zuerst vermutet) die Option ist die clipped ist ja ein alter Hut, daher fahre ich bei DNxHD immer in der 709 Option in welcher ich noch nie einen Shift hatte (auch nicht in Adobe).
Haste denn selbst schon die Avid LE 2.6 installiert und da mal rein geschaut oder lässt nur "Fakten" vom Stapel die hinlänglich bekannt sind ohne es mal probiert zu haben?
Antwort von dienstag_01:
Dass RGB (entgegen dem, was man gerne zuerst vermutet) die Option ist die clipped ist ja ein alter Hut, daher fahre ich bei DNxHD immer in der 709 Option in welcher ich noch nie einen Shift hatte (auch nicht in Adobe).
Das ist natürlich falsch. Oder besser, kann nur funktionieren, wenn man aus einer Application kommt, die Full Range arbeitet. Wenn man in der Legal Range arbeitet clipped bei RGB nichts und 709 wird in Adobe falsch importiert.
Ich denke, du sprichst von Resolve und da kann man ja die Ranges umstellen. Sollte man aber mit einem anderen Tool konvertieren ist es genau umgekehrt.
Ich hab die Codecs installiert, aber keine Zeit, groß zu testen. Ausserdem arbeiten die Codecs aus dem Pack ja nicht innerhalb von Avid, da brauch man die Version 8.xx. Die hab ich hier nicht.
Antwort von CameraRick:
Nein ich spreche nicht vom Resolve, die DNxHR sind ja, wie vorhin schon gesagt, problemlos was den Shift angeht.
Du sagst nun es sei per se falsch, dass das mit DNxHD aber kein Problem ist hast Du aber auch verstanden? Und dass es bei beiden Modi passiert?
Was der Avid macht ist mir, das hast Du vielleicht nicht ganz rausgehört, Schnurzpiepe. Mir geht es um die Verwendung in anderer Software, wie das mit DNxHD schon problemlos lief, aber nun nicht mehr geht :)
Antwort von dienstag_01:
Vielleicht erläuterst du mal, wie und was genau du überhaupt vergleichst.
Adobe Software Gammashift im Vergleich zu ...
Antwort von CameraRick:
Ich nehme eine Source, wobei jetzt völlig egal ist woher die kommt.
Privat nutze ich keinen Mac, ergo fällt Prores zunächst weg (theoretisch nicht, weil ich Miraizon Kunde war, aber nehmen wir es mal an). Ich mag jetzt was rendern, und da ich privat Einzelbilder blöd finde gern in einen Intermediate Codec.
Nehmen wir an, ich gehe durchs DaVinci und will dort raus, dann muss ich was rendern; am Mac mach ichs in Prores, am PC nehme ich gern auch mal DNxHD.
Aber nicht nur aus dem DaVinci will ich raus, ich will auch aus dem Nuke, dem AE, dem Premiere oder dem Fusion hinaus.
Also, das ist der Zweck des Codecs, wozu ich ihn nutzen will, nicht der Testaufbau.
Mein "Testaufbau" (das klingt größer als es ist) ist eine in AE generierte Sequenz mit div Verläufen und Bewegung, dazu ein ARRIRAW clip direkt importiert.
Diese rendere ich raus mit verschiedenen Codecs, zB PR4444, DNxHR in verschiedenen Geschmäckern, etc
Dann importiere ich die einfach wieder hinein und vergleiche sie mit einander, wie gut sie keyen oder graden oder whatever. DNxHD, Prores (in jedem Geschmack) und alle anderen kriegen es hin keinen Gammashift zu produzieren, DNxHR444 schafft das auch - aber DNxHR in 422 10bit schafft das nicht, weder 709 noch in RGB.
Und das in jeder Software in der ich die Clips öffnen kann (DaVinci liest ja die MOVs nicht).
Aus Fusion und Nuke hinaus zu rendern habe ich noch nicht geschafft.
Antwort von dienstag_01:
Ok, versteh ich, schau ich mir mal an (aber nicht jetzt).
Was mich noch interessieren würde: welche Farbtiefe dein Projekt hat und ob du einen Farbraum verwendest?
Achso, und was ist mit dem Gammashift, bei beiden Varianten (709 und RGB) gleich?
Antwort von wolfgang:
Achso, Du nimmst natives Material, vermutlich aus Deinem Shogun?
Ich meine speziell jetzt nur Codecs, die via dem Codec-Package auch enkodiert wurden.
Na klar, das ist hier ein Shogun Thread - und damit gehts hier mal um das aufgezeichnete Material und davon habe ich gesprochen.
Wie sich das neue Codec Package verhält, wenn man es aus einem Adobe Produkt encodiert - keine Ahnung. Hat ja mit dem Shogun wenig zu tun.
Antwort von CameraRick:
Stimmt ja, weil wir hier ja nie vom Thema abkommen ;)
Wäre halt gut wenn man auch in dem Codec bleiben kann und nicht wechseln muss, ist ja nachher auch für Dich interessant, also ggf.
Was mich noch interessieren würde: welche Farbtiefe dein Projekt hat und ob du einen Farbraum verwendest?
32bit, Farbraum ist nicht verstellt. Problem tritt aber auch im AME auf, der ist von diesen Fragen ja quasi schon "ausgenommen"
Achso, und was ist mit dem Gammashift, bei beiden Varianten (709 und RGB) gleich?
Würde behaupten ja, habs nicht näher untersucht aber wirkte ziemlich identisch
Antwort von wolfgang:
Ja klar ist das auch für mich von Interesse. Ich will das noch in Ruhe austesten - aber für meinen alten i7 2600K ist wohl auch dieser Codec zu wenig performat.
Aber wenn wenigstens die Luma-Darstellung stimmig ist, heißt das immerhin dass man in Produkten wie dem Shogun für die weitere Verarbeitung des Shogun-Materials vermutlich besser in DNxHR aufnimmt, und das dann (für meinen Zweck) vermutlich wieder zu Cineform transkodiert.
Denn die Playback-Performance ist halt nur ein Teil der Rechnung. Der andere - wichtigere - Teil ist die Frage, ob DNxHR in Applikationen wie Vegas oder Edius auch als 10bit dekodiert werden (halt im Original aus Shogun und GH4 in 10bit vorliegend, je nach eingestellter DNxHR Qualität). Für Vegas haben wir Wege wie man das halbwegs gesichert feststellen kann - und in derzeitigen Entwicklungstand von Vegas vermute ich eher, dass der Codec in dieser Applikation auch nur als 8bit dekodiert wird. Bei Edius ist das übrigens meines Erachtens auch noch unklar. So gesehen müssen wir diesen Codec noch weiter austesten.
Antwort von merlinmage:
Das zu dienstags DNxHR Wundercodec. Ganz großes Kino ;)
Antwort von CameraRick:
Ich will das noch in Ruhe austesten - aber für meinen alten i7 2600K ist wohl auch dieser Codec zu wenig performat.
Ach wieso? So ein All-I Codec sitzt doch immer viel angenehmer auf der CPU. Von der Datenrate her ist der ja direkt mit DNxHD vergleichbar, erlaubt eben nur höhere Datenraten.
Wenn Du natürlich 4K abgreifst sinds wohl eher die Festplatten, die da Probleme bekommen :)
Antwort von wolfgang:
Völlig richtig das es all-i codecs sind. Und wir erwarten von der HD-Welt kommend so ein Verhalten nicht - aber es ist die Dekodierleistungen die leider bei UHD/4K zu gering ist.
Klar liegen die Datein entweder auf SSDs oder auf Raid-Systemen. Dass diese Leistung zu gering ist haben wir aber schon ausschließen können.
Antwort von CameraRick:
Tatsächlich hätte ich der CPU da mehr zugetraut, ich hatte diese Probleme bisher zugegeben noch nicht (aber fahre auch auf neueren CPUs). Gut zu wissen, Danke Dir :)
Find ich persönlich nicht so schlimm, Proxys tuns zum Schneiden auch.
Antwort von dienstag_01:
Ich hab mal einen kurzen Test mit dem DNxHR Codec gemacht:
- relativ unklares Verhalten in After Effects
- vollkommen unklares Verhalten in Avid (MC7)
Die Ergebnisse beziehen sich auf die 10bit Variante, getestet wurde der Codec für die Übergabe zwischen Video Applikationen (also nicht aus der Cam), Format war 1080p25.
Was ist der Fehler: manche nennen es Gammashift, in der wirklichen Wirklichkeit ;) ist es aber eine Fehlinterpretation der Luma Range.
Zum Vergleich lief immer eine Datei in DNxHD mit, hier war das Verhalten wie erwartet.
Ich hatte einfach nur getestet, ohne mir irgendwelche Informationen oder Hintergründe/Einschränkungen zum Codec einzuholen. (Vielleicht gibt es die ja)
Was das nun bedeuten soll... ;)
Antwort von CameraRick:
Danke für die Info!
Haste jetzt selber auch noch einmal bei Null angefangen oder direkt gesehen dass es nicht nur Stuss war, von dem ich sprach? :P
Ich zweifle ehrlich gesagt daran dass es nur eine Fehlinterpretation der Luma-Range ist; die ist nämlich ziemlich einfach zu korrigieren. Bei einer derartigen Korrektur verhält sich das Material aber anders.
Ein klassischer Gammashift wirds dann wohl auch nicht sein; ist mir auch Wumpe, das ist ein Streit um Worte. Das Material verhält sich nach der Korrektur nicht so, wie es sollte, und es liegt ein deutlicher Unterschied vor.
Ich vermute, dass der Codec vielleicht einfach noch nicht final ist.
Was dafür spricht, dass der Codec auch noch gar nicht auffindbar ist, wenn man nicht Chris' Link folgt; also, noch kein "offizielles" Release vorliegt.
Was ich übrigens witzig zu beobachten finde:
In AE muss man ja für gewöhnlich "Millions of Colors" und "Trillions of Colors" auswählen, damit man 8 bzw 10bit bekommt. Bei DNxHD 444 gab "Trillions of Colors" allerdings immer massive Probleme, eine Ausgabe auf "Millions of Colors" war allerdings auch relativ eindeutig nicht nur 8bit stark.
DNxHR bietet hier nun gar keine Auswahl mehr, sondern ist immer "Millions of Colors"; ich behaupte aber auch hier, dass dennoch 10bit gerendert werden.
Bei Miraizon auf Windows werden bei den verschiedenen Einstellungen übrigens die Files anders gerechnet (die eine Art wird dann nicht mehr gedithert, die andere schon; sie ist dann viel kleiner in der Dateigröße (bei generierten Bildern); mehr als 8bit scheinen beide zu haben)
An dieser Stelle würde ich mir wünschen, dass AE einfach mal eindeutige Bezeichnungen nehmen würde; bzw sie ganz weg lassen, der Codec soll das entscheiden.
Antwort von dienstag_01:
Ich zweifle ehrlich gesagt daran dass es nur eine Fehlinterpretation der Luma-Range ist; die ist nämlich ziemlich einfach zu korrigieren.
Ist es auch bei mir, mit Farbmanagment.
(Deshalb hatte ich *relativ* unklares Verhalten geschrieben)
Ich vermute, dass der Codec vielleicht einfach noch nicht final ist.
Der Codec schon, aber vielleicht noch nicht das Codec Pack.
Irgendwie aber trotzdem komisch.
