slashCAM Forum

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

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?

Nathanjo hat geschrieben: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

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.

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

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

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. ;)

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.

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.

Du hast keine Ahnung, stimmts?

das ist der grund, warum ich frage.

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!

danke.

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.

danke auch dir.

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.

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.

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.

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

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.

WoWu hat geschrieben: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?

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).

danke für eure ganzen tipps.

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

WoWu hat geschrieben: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...

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.

WoWu hat geschrieben: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...