slashCAM Forum

cantsin hat geschrieben: ↑Fr 09 Jun, 2023 10:51

dienstag_01 hat geschrieben: ↑Fr 09 Jun, 2023 00:18 18-32 Mbit, das ist ja stolz. Ich bin inzwischen bei 8 (so ungefähr) ;)

dienstag_01 hat geschrieben: ↑Fr 09 Jun, 2023 00:51 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

dienstag_01 hat geschrieben: ↑Fr 09 Jun, 2023 11:08 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 hat geschrieben: ↑Fr 09 Jun, 2023 12:27

dienstag_01 hat geschrieben: ↑Fr 09 Jun, 2023 11:08 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 hat geschrieben: ↑Fr 09 Jun, 2023 12:42 Und wenn man jetzt noch die Komprimierung von Youtube und Co draufrechnet, dann Goodby auch letzte kleine Unterschiede.
Das ist meine Erfahrung.

cantsin hat geschrieben: ↑Fr 09 Jun, 2023 13:00

dienstag_01 hat geschrieben: ↑Fr 09 Jun, 2023 12:42 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.)