Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Adobe Premiere Pro / Elements / SpeedGrade / Creative Cloud CC-Forum

Infoseite // Avid DNxHD Codec



Frage von Benutzername:


moin!

ist es normal, dass ein clip von 16 sekunden und einer größe von 90 mb nach dem exportieren in den DNxHD codec 370 mb groß wird? premiere pro. keine effekte. videogröße:
1920 x 1080
24 bit tiefe
25 fps
feldfolge: progressiv

wie kann ich die mb kleiner halten mit dnxhd?

danke
bn

Space


Antwort von Nathanjo:

Ohne gerade fähig zu sein das auszurechnen klingt das vollkommen normal. Eine niedrigere Bitrate zu wählen würde die Größe etwas verringern. Aber das ist nunmal kein Codec der für effektive Kompression gedacht ist, sondern für hohe Qualität während der Bearbeitung. Schon garnicht bei 24 bit Farbtiefe. Sind die nötig?

Space


Antwort von srone:

Schon garnicht bei 24 bit Farbtiefe. Sind die nötig? ich denke er meint 3 mal 8bit (rgb), ansonsten stimme ich dir zu.

lg

srone

Space


Antwort von Benutzername:

ich bin vielleicht ein depp. sorry,

Mit maximaler Tiefe rendern

war gar nicht angeklickt. das heißt, 24 bit waren nicht ausgewählt. sorry, für das mißverständnis. wenn ich auf

codec-einstellung

gehe, steht da 10 bit.

aber ich habe jetzt mal spaßeshalber

Mit maximaler Tiefe rendern - 24 Bit

angelickt. selbe größe wie mit ohne anklicken. was für ein deutsch ;)

also gehen meine möglichkeiten gegen 0, das video kleiner rauszurendern?

wenn ich unter

codec-einstellung

8 bit einstelle, bleibt es auch bei der selben größe.

Space


Antwort von Jake the rake:

DNxHD 36 eingestellt? Kleiner geht nicht. Audio auf 16bit?

Space


Antwort von srone:

mit max bittiefe rendern bedeutet, dass intern, vor der komprimierung, das signal mit 32bit berechnet wird, komprimiert wird allerdings je nach codec idr mit 8 bzw 10 bit.

wenn du es kleiner willst -> h-264.

lg

srone

Space


Antwort von Benutzername:

habs jetzt mal mit 36 gerendert. wird viel kleiner. danke. audio steht bei mir auf AAC. wo stelle ich audio auf 16 bit ein?

h-264 ist aber ekelig. ;)

Space


Antwort von Nathanjo:

Vielleicht wäre die Frage wofür das Video komprimiert werden soll? Also was ist in diesem Fall der Endzweck? DNxHD würde man nur nutzen wenn es um maximale Qualität und geringe Prozessorlast geht. Da muss man mit den großen Dateien halt leben.

H.264 in sehr guten Einstellungen ist für die Ausgabe die bessere Wahl, wenn die Datei nicht zu groß sein darf. Der Codec ist halt effektiv, dafür rechenaufwändiger.

Space


Antwort von Benutzername:

youtube. aber ich habe nur eine canon 600d, leider immer noch mit kit objektiv, und die qualität ist echt würg. wenn ich jetzt noch in h-264 rausrender, was ich schon getan habe, dann verliere ich noch mehr an quali. kauft euch blos keine canon. lieber auf gh4 sparen und rechner aufrüsten.

Space



Space


Antwort von gekkonier:

Du hast keine Ahnung, stimmts?

Space


Antwort von Benutzername:

das ist der grund, warum ich frage.

Space


Antwort von gekkonier:

Youtube kann mit dnxhd nix anfangen, das wäre der falsche Weg.

Und bei H264 kannst du die Bitrate hochdrehen. Da würde ich mal mit Testclips anfangen, bis du ein Setting findest das dir passt. Youtube frisst H264, und wenn da die Bitrate hoch genug ist wird das auch was ;)

Viel Glück!

Space


Antwort von Benutzername:

danke.

Space


Antwort von Nathanjo:

H.264

VBR 2-pass

10 Mbit, 15 Mbit max.


Bei Bedarf die Bitrate noch höher drehen. Das sind gute Einstellungen für YouTube, wo man an der Qualität wirklich nicht mehr meckern kann.

Space


Antwort von Benutzername:

danke auch dir.

Space


Antwort von WoWu:

Und wenn Du mit RAW aus der Canon kommst, geh gleich in H.264, ohne Umweg über MPEG2 (DNxHD), da verlierst Du nämlich bereits diverse Qualität, die Du hinterher nicht mehr aufholen kannst.

Space


Antwort von Bergspetzl:

Und auch die canon zeichnet intern h.264 auf. Also wandeln bringt nur in sachen 'flutsch' etwas, aber zu kosten der quali wegen der konversation... Aus raw ein dpx oder dnxhd master zum arbeiten zu erstellen finde ich hingegen nicht problematisch. Fürs finale dann exportieren, in was notwendig ist.

Space


Antwort von WoWu:

Problem bei einem Übergang (erst zu MPEG2) besteht immer darin, dass beispielsweise die Makroblockgrösse fixiert wird.
Geht man also hinterher auf einen H.264, der sehr viel kleinere und auch flexiblere Makroblöcke vorsieht, geht das nicht mehr, weil der Vorcodec einem das schon fixiert hat.
Dasselbe betrifft die DCT. H.264 arbeitet mit einer ItegerDCT, die ausschliesslich mit Additionen und Shifts arbeitet, anders als die DCT, die in DV und MPEG2 benutzt wurde und die entsprechende Rundungsfehler erzeugt, die sich primär auf die Farbqualität auswirken.
Also: aus RAW immer gleich nach H.264, um die maximale Qualität zu erzeugen. (oder eben auf ein AVC-I oder XAVC I-Format)
Wer einen zu schwachen Rechner hat, sollte sich von Video- nach Audioverarbeitung verlegen. MP3 Files gehen auch auf einem 64er Modell. ;-)
Aber oft sparen die NLEs natürlich an Encodierlizenzen. Das ist das häufigere Problem.

Space



Space


Antwort von CameraRick:

WoWu,

willst Du damit sagen dass sich DNxHD generell nicht als Intermediate eignet? Wie sieht es mit ProRes aus?


zum Thema: DNxHD36 ist zwar klein, aber die Makroblöcke der Horror. Als Proxy halt gut zu gebrauchen, sonst nicht so. Da lieber ein h.264 mit gleicher Bitrate (oder sogar "nur" 20mbit), das sieht dann auf YouTube auch deutlich besser aus.
Ansonsten kann man auch bei DNxHD120 bleiben, da bist dann etwas kleiner als beim 185x unterwegs.
Was das AAC im DNxHD verloren hat verstehe ich nicht

Space


Antwort von WoWu:

Ich will nun nicht die Mietmäuler, hier im Forum, auf den Plan rufen, aber wer den Unterschied zwischen den DCTs kennt und die Veränderungen, die bei der Weiterentwicklung der Codecs gemacht worden sind, lässt die Finger von solchen Codecs, egal wie sie heissen.

Und bevor gleich wieder einer kommt und von "weltweiterm Standard" dröhnt, ... VHS war auch ein weltweiter Standard.
Es ist immer eine Frage, welche Anforderung man an die Qualität seines Produktes stellt.
Für schnelle EB Sachen mag das alles ausreichen.

Space


Antwort von Nathanjo:

Ich will nun nicht die Mietmäuler, hier im Forum, auf den Plan rufen, aber wer den Unterschied zwischen den DCTs kennt und die Veränderungen, die bei der Weiterentwicklung der Codecs gemacht worden sind, lässt die Finger von solchen Codecs, egal wie sie heissen.

Und bevor gleich wieder einer kommt und von "weltweiterm Standard" dröhnt, ... VHS war auch ein weltweiter Standard.
Es ist immer eine Frage, welche Anforderung man an die Qualität seines Produktes stellt.
Für schnelle EB Sachen mag das alles ausreichen. Das ist mir neu und ich habe das Gefühl etwas lernen zu können:

Also heißt das wenn ich z.B. für visuelle Effekte einzelne Einstellungen als DNxHD rausrendere ist das für die spätere Kompression nach H.264 kontraproduktiv?

Space


Antwort von WoWu:

Wenn Dein Original H.264 ist, ja.
Du musst Dir die Parameter von AVC mal anschauen und sie dann mit MPEG2 Parametern vergleichen, dann siehst Du schon mal den bildbezogenen Unterschied und dazu wechselst Du noch von einer IDCT, die mit Addition und Shifts also absolut reproduzierbar arbeitet, in eine Berechnung, die gegen Rundungsfehler zu kämpfen hat.
Hinterher ist das Bildmaterial nur noch so gut, wie der schlechteste Teil der Bearbeitung.
Das Problem ist eben nur, dass die NLEs noch ein Jahrzehnt hinter den Codecs herdackeln und H.264 aus den unterschiedlichsten Gründen z.Tl. gar nicht können, so dass man manchmal gar keine Wahl hat.
Nur das ändert nichts daran, dass der "native" Weg der deutlich Bessere für die Bildqualität ist.
(Mal ganz von den 8bit- 10bit -8Bit Roundtrips abgesehen, die ihr Übriges an Bildminderung nach sich ziehen, weil das Signal einmal gespreizt und wieder gestaucht wird).

Space


Antwort von Benutzername:

danke für eure ganzen tipps.

Space


Antwort von Jott:

Unter den Blinden ist der Einäugige König.

Space


Antwort von Nathanjo:

Wenn Dein Original H.264 ist, ja.
Du musst Dir die Parameter von AVC mal anschauen und sie dann mit MPEG2 Parametern vergleichen, dann siehst Du schon mal den bildbezogenen Unterschied und dazu wechselst Du noch von einer IDCT, die mit Addition und Shifts also absolut reproduzierbar arbeitet, in eine Berechnung, die gegen Rundungsfehler zu kämpfen hat.
Hinterher ist das Bildmaterial nur noch so gut, wie der schlechteste Teil der Bearbeitung.
Das Problem ist eben nur, dass die NLEs noch ein Jahrzehnt hinter den Codecs herdackeln und H.264 aus den unterschiedlichsten Gründen z.Tl. gar nicht können, so dass man manchmal gar keine Wahl hat.
Nur das ändert nichts daran, dass der "native" Weg der deutlich Bessere für die Bildqualität ist.
(Mal ganz von den 8bit- 10bit -8Bit Roundtrips abgesehen, die ihr Übriges an Bildminderung nach sich ziehen, weil das Signal einmal gespreizt und wieder gestaucht wird). Was wäre denn der sinnvollste Weg, wenn man das Material nicht unbearbeitet lassen kann? Lieber wieder in H.264 zwischenkodieren (wenn auch in hoher Bitrate)? Das wirkt auf den ersten Blick irgendwie absurd auf mich, könnte aber zugleich eine Lösung sein. Unkomprimiert oder lossless komprimiert kommt bei vielen Sachen nicht in Frage - zu riesig für meinen bescheidenen Workflow.

Ich glaube tatsächlich Bildprobleme bemerkt zu haben, die ich auf die Kompression auf DNxHD zurückführen würde...

Space


Antwort von WoWu:

Wenn Du aus H.264 kommst, am Besten in AVC bleiben.
Diese ganze Umcodiererei ist eigentlich ein Relikt aus der Zeit, als die Rechner das noch nicht so richtig packten.
Ansonsten, ein Proxy workflow oder einen I-Frame Codec aus AVC benutzen.
Aber meistens packen die Rechner das 264 Material nativ.

Space


Antwort von Nathanjo:

Wenn Du aus H.264 kommst, am Besten in AVC bleiben.
Diese ganze Umcodiererei ist eigentlich ein Relikt aus der Zeit, als die Rechner das noch nicht so richtig packten.
Ansonsten, ein Proxy workflow oder einen I-Frame Codec aus AVC benutzen.
Aber meistens packen die Rechner das 264 Material nativ. Das native Schneiden ist auch kein Problem, es geht vor allem darum wenn Einstellungen bearbeitet werden für visuelle Effekte. Ich werde direkt mal testen ob ich die Bildfehler, die ich bemerkt habe so weg bekomme.

Allerdings finde ich das alles ein wenig seltsam, weil die Fehler in der Vorschau von Premiere nicht auftauchen, aber nach dem Rendern in H.264 mit hoher Bitrate schon. Eigentlich sollte es als Zwischenschritt doch komplett unkomprimiert verarbeitet werden intern, schon allein weil soviele Effekte darauf liegen. Kann mit meinem begrenzten Wissen nicht ganz nachvollziehen warum die vorige Kompression Einfluss auf die neue Kompression haben soll (außer von Qualitätseinbußen, die aber wie gesagt in der Premiere-Vorschau nicht existieren, sondern erst NACH dem Rendern).


Edit: Nein, daran liegts nicht. Ich werd dazu mal einen neuen Thread aufmachen...

Space



Space


Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Adobe Premiere Pro / Elements / SpeedGrade / Creative Cloud CC-Forum

Antworten zu ähnlichen Fragen //


avid codec
Avid Codec
AVID MC 6: DNXHD zu MOV zurück verlinken
Wie EOS zu AVID DNxHD wandeln
Avid DNxHD Codec
Verwirrung bei VideoAssist-DNxHD Codecs
AVI-Datei mit Indeo Video 4.4-Codec in anderen Codec umwandeln
Avid Media Composer 2019 ist da mit neuer Media Engine und Workspaces, 16K Finishing und mehr
Blackmagic RAW 1.5 bringt kostenlose Plugins für Adobe Premiere Pro und Avid Media Composer // IBC 2019
Avid Media Composer bekommt ProRes RAW Unterstützung // IBC 2019
Schießt Avid reihenweise Mac Pros in Hollywood-Studios ab?
Trailer Schnitt im Avid
Blackmagic: Desktop Firmware Update 11.4.1 bringt HDR Unterstützung für Avid Media Composer
Am Avid Samsung Monitor bleibt schwarz
Am Avid / blackmagic Community 4k Samsung Monitor bleibt schwarz
Avid Nutzung mit NAS-System möglich?
Schnittliste für Sender aus AVID
Nach 20 Jahren Avid auf FCPX wechseln
Avid User Settings
AVID MC - R128 bei 5.1 bzw 7.1
Adobe und Avid stellen befristete, freie Softwarelizenzen für Home-Office zur Verfügung
Avid Media Composer 2020.4 bringt Support für macOS Catalina und ProRes
Update: Kyno 1.8 mit BRAW-Support und DaVinci Resolve / Avid Media Composer Unterstützung




slashCAM nutzt Cookies zur Optimierung des Angebots, auch Cookies Dritter. Die Speicherung von Cookies kann in den Browsereinstellungen unterbunden werden. Mehr Informationen erhalten Sie in unserer Datenschutzerklärung. Mehr Infos Verstanden!
RSS Suche YouTube Facebook Twitter slashCAM-Slash