Voukoder macht was es will! Thema ist als GELÖST markiert

[dienstag_01]

18-32 Mbit, das ist ja stolz. Ich bin inzwischen bei 8 (so ungefähr) ;)

Ja, so ähnlich hab ich auch mal gedacht. Bis zu x264 ;)

8000k gehen natürlich, wenn Du relativ glattes Ausgangsmaterial hast - entrauscht, ohne viel Bewegung und mit nur soviel Details/Texturen im Bild, wie sie z.B. für Innenräume typisch sind.

Ich habe gerade mal spaßeshalber einen Praxistest mit eigenem Material gemacht, das ganz gut die Grenzen von 8000 KBit/s-x264 aufzeigt. Ausgangspunkt war Raw aufgenommenes Material, das in Resolve geschnitten/bearbeitet und nach DNxHR rausgerendert war.

Encodierung nach h264 (mit dem x264-Encoder) einmal nach 8000k 2-pass und einmal nach 32000k 2-pass, mit der folgenden ffmpeg-Kommandozeile:

Code: Alles auswählen

ffmpeg -i input.mxf -c:v libx264 -tune grain -preset veryslow -profile:v high -level 5.2 -pix_fmt yuv420p -b 8000k -pass 1 -y output-8000.mp4
ffmpeg -i input.mxf -c:v libx264 -tune grain -preset veryslow -profile:v high -level 5.2 -pix_fmt yuv420p -b 8000k -pass 2  -y output-8000.mp4

...und das ganze nochmal entsprechend abgewandelt (mit "-b 32000k") für das 32MBit/s-Encoding.

Hier Screengrabs mit den jeweiligen Ergebnissen, einmal mit dem Motiv ohne Bewegung im Bild und einmal mit Bewegung:


002-32000.png
statisches Motiv, x264 32 MBit/s


002-8000.png
statisches Motiv, x264 8 Mbit/s



002-32000-crop.png
1:1-Ausschnitt, x264 32 MBit/s


002-8000-crop.png
1:1-Ausschnitt, x264 8 MBit/s





033-32000.png
Bewegtes Motiv, x264 32 MBit/s


033-8000.png
Bewegtes Motiv, x264 8 MBit/s



033-32000-crop.png
1:1-Ausschnitt, x264 32 MBit/s


033-8000-crop.png
1:1-Ausschnitt, x264 8 MBit/s

Interessant wäre der Vergleich ohne tune grain, denn das ist natürlich ein zum Scheitern verurteilter Versuch, Datenrate sparen aber Grain erhalten ;)

Ich nutze ja gerade das Encoding zum Entrauschen.

[cantsin]

Interessant wäre der Vergleich ohne tune grain, denn das ist natürlich ein zum Scheitern verurteilter Versuch, Datenrate sparen aber Grain erhalten ;)

Voilà:

002-8000.png

8 Mbit/s

002-32000.png

32 Mbit/s



Ausschnitt 1:

002-8000-crop_1.png

8 Mbit/s

002-32000-crop_1.png

32 Mbit/s



Ausschnitt 2:

002-8000-crop_2.png

8 Mbit/s

002-32000-crop_2.png

32 Mbit/s

Ich nutze ja gerade das Encoding zum Entrauschen.

Ich nehme für sowas lieben einen echten Entrauscher im NLE (= Neat). Denn was Dir x264 da als 'Entrauschung' macht, ist ja eher Verschmieren/Macroblocking...

[dienstag_01]

Interessant wäre der Vergleich ohne tune grain, denn das ist natürlich ein zum Scheitern verurteilter Versuch, Datenrate sparen aber Grain erhalten ;)

Voilà:


002-8000.png
8 Mbit/s


002-32000.png
32 Mbit/s



Ausschnitt 1:


002-8000-crop_1.png
8 Mbit/s


002-32000-crop_1.png
32 Mbit/s



Ausschnitt 2:


002-8000-crop_2.png
8 Mbit/s


002-32000-crop_2.png
32 Mbit/s

Ich nutze ja gerade das Encoding zum Entrauschen.

Ich nehme für sowas lieben einen echten Entrauscher im NLE (= Neat). Denn was Dir x264 da als 'Entrauschung' macht, ist ja eher Verschmieren/Macroblocking...

Und wenn man jetzt noch die Komprimierung von Youtube und Co draufrechnet, dann Goodby auch letzte kleine Unterschiede.
Das ist meine Erfahrung.

[cantsin]

Und wenn man jetzt noch die Komprimierung von Youtube und Co draufrechnet, dann Goodby auch letzte kleine Unterschiede.
Das ist meine Erfahrung.

Natürlich. Aber wenn Du z.B. Vimeo nutzt, gibt es da die Option, dass Nutzer das hochgeladene (Master-) Video runterladen können, und schon dafür lohnt sich das. Wobei auch der Streaming-Codec von Vimeo ziemlich gut (=deutlicher besser als YouTube & Co) darin ist, Details inkl. Bildrauschen/Korn zu bewahren. (Was auch so ziemlich der letzte Grund ist, um Vimeo überhaupt noch nutzen...)

Ein anderer Punkt ist, dass beim Re-encoding durch YouTube & Co. natürlich neue Blockartefakte hinzu kommen, und es dann aus meiner Sicht besser ist, wenn die Masterdatei die nicht schon hat, damit sich nicht zwei Generationen/Layer von Macroblocking addieren...

8 MBit/s ist aber definitiv die probatere Lösung, wenn man dem Kunden/Endabnehmer eine Datei zuschickt. Ich arbeite in Resolve mit Group Nodes, die ich ähnlichem Material zuordne. Da kann ich dann in der Pre-Group-Node eine Neat-Node anlegen, die für dieses jeweilige Material optimiert ist und in einem Rutsch eine ganze Serie Clips entrauscht. Beim Schneiden schalte ich die aus, aktiviere sie dann aber vorm Rausrendern eines speziellen rauschgefilteren DNxHR (neben dem ungefilterten DNxHR), um das dann als Master für eine x264-Encodierung mit niedrigerer Bitrate zu nehmen.

- Auch hier kann man natürlich sich ggfs. den Umweg über DNxHR sparen und direkt via Voukoder rendern. Ist in dem speziellen Anwendungsfall (entrauschtes Low-Bitrate-mp4 als Zieldatei) wahrscheinlich sogar effizienter. (Um damit wieder on-topic zu werden.)

[dienstag_01]

Und wenn man jetzt noch die Komprimierung von Youtube und Co draufrechnet, dann Goodby auch letzte kleine Unterschiede.
Das ist meine Erfahrung.

Natürlich. Aber wenn Du z.B. Vimeo nutzt, gibt es da die Option, dass Nutzer das hochgeladene (Master-) Video runterladen können, und schon dafür lohnt sich das. Wobei auch der Streaming-Codec von Vimeo ziemlich gut (=deutlicher besser als YouTube & Co) darin ist, Details inkl. Bildrauschen/Korn zu bewahren. (Was auch so ziemlich der letzte Grund ist, um Vimeo überhaupt noch nutzen...)

Ein anderer Punkt ist, dass beim Re-encoding durch YouTube & Co. natürlich neue Blockartefakte hinzu kommen, und es dann aus meiner Sicht besser ist, wenn die Masterdatei die nicht schon hat, damit sich nicht zwei Generationen/Layer von Macroblocking addieren...

8 MBit/s ist aber definitiv die probatere Lösung, wenn man dem Kunden/Endabnehmer eine Datei zuschickt. Ich arbeite in Resolve mit Group Nodes, die ich ähnlichem Material zuordne. Da kann ich dann in der Pre-Group-Node eine Neat-Node anlegen, die für dieses jeweilige Material optimiert ist und in einem Rutsch eine ganze Serie Clips entrauscht. Beim Schneiden schalte ich die aus, aktiviere sie dann aber vorm Rausrendern eines speziellen rauschgefilteren DNxHR (neben dem ungefilterten DNxHR), um das dann als Master für eine x264-Encodierung mit niedrigerer Bitrate zu nehmen.

- Auch hier kann man natürlich sich ggfs. den Umweg über DNxHR sparen und direkt via Voukoder rendern. Ist in dem speziellen Anwendungsfall (entrauschtes Low-Bitrate-mp4 als Zieldatei) wahrscheinlich sogar effizienter. (Um damit wieder on-topic zu werden.)

Für Vorschau nehme ich meist 3,5 Mbit ;)

Ich habe mich von diesen Bildvergleichen innerlich verabschiedet, ich schaffe es sowieso nicht, die Qualität bis zum letzten Screen konsistent zu halten.
(Ich erinner mich, den Filmkartons von Lynch's Wild at Heart oder Lost Highway lag immer ein "persönlicheres" Anschreiben des Regisseurs bei, im Kino bitte auf perfekte Vorführbedingungen zu achten, damit alles stimmt.)
Daher schau ich bei Youtube nochmal drauf, da muss es gut aussehen (funktionieren), das ist Teil des Gestaltungsprozesses (der ist also nicht mit der NLE-Ausgabe beendet).

Edit: Ich gebe allerdings auch mal ein DCP raus, ich rechne jetzt nicht alles so klein ;)