Videos konvertieren mit CRF statt 2-Pass - gute Anleitung gesucht

[autoshot]

Hallo zusammen!

Um iCloud Speicherplatz zu sparen konvertiere ich seit Jahren meine diversen GoPro/ DJI/ iPhone-Videos von 4K H.264/265 auf 1080p H.265, und zwar via 2-Pass Encoding bei vorgegebener Bitrate. Das hat bisher eigentlich immer ganz gut funktioniert, auch wenn Encoding via CRF wohl besser sein soll hinsichtlich Qualität/Dateigröße. Mit CRF hab ich allerdings bisher nur schlechte Erfahrungen gemacht (Qualität schlechter bei größerer Dateigröße), weshalb ich davon ausgehe, dass ich da irgendwas falsch mache.

Daher die Frage: kennt jemand von euch eine gute Anleitung zum Thema CRF, also wie man den Encoder korrekt konfiguriert, damit was Vernünftiges dabei rauskommt?

Liebe Grüße,
autoshot

 

[madmax2010]

https://trac.ffmpeg.org/wiki/Encode/H.265

scroll zu crf, da ist es erläutert

und setz einfach die lossless flag. Die impliziert denke ich alles was du willst

 

[motorazrv3]

zwar via 2-Pass Encoding bei vorgegebener Bitrate.

Das kann doch auch schlecht werden bei schlecht gewählter vorgegebener Bitrate und auch encoding Parameter.

dass ich da irgendwas falsch mache.

Der CRF Parameter ist ja nicht der alleiniger Faktor, welcher die Qualität des Encodes bestimmt. Da gibt es bei x265 ja noch jede Menge anderer Stellschrauben.

hat bisher eigentlich immer ganz gut funktioniert,

Dann bleib doch dabei! Der Vorteil ist halt, die vorgegebene Größe der Datei oder Bitrate des Videos wird halt eingehalten. Was halt bei CRF nicht möglich / gegeben ist.

 

[T00L]

Eigentlich sind es nur wenige Parameter, um die du dich kümmern müßtest:
SW Encoder ist einem HW Encoder vorzuziehen
Preset slow oder very slow
CRF zwischen 20-23 bei HD Material

 

[autoshot]

Das kann doch auch schlecht werden bei schlecht gewählter vorgegebener Bitrate und auch encoding Parameter.

Eben genau das ist so ein bisschen das Problem gerade: standardmäßig konvertiere ich z.B. 4K60 auf 1080p60 bei durchschnittlich 4000kbits. Das funktioniert meistens, manchmal aber eben nicht (z.B. gestern) und dann darf ich nochmal und nochmal und nochmal mit verschiedenen Bitraten konvertieren bis die Videoqualität zufriedenstellend ist. Entsprechend wärs natürlich schon ganz angenehm, wenn ich mir diese Herumprobiererei sparen könnte...

Der CRF Parameter ist ja nicht der alleiniger Faktor, welcher die Qualität des Encodes bestimmt. Da gibt es bei x265 ja noch jede Menge anderer Stellschrauben.

Das ist das Nächste. Gefühlt kann man 1000 Sachen einstellen, welche Einstellung was bewirkt und unter welchen Voraussetzungen gewählt werden sollte - keine Ahnung

 

[madmax2010]

so kannst du dir das durchiterieren:
for i in {1..51}; do ffmpeg -i input.mp4 -c:v libx265 -crf $i output_crf_$i.mp4; done
so vergleichsscreenshots von einem timestamp erstellen:
for i in {1..51}; do ffmpeg -ss 00:12:34 -i output_crf_$i.mp4 -frames:v 1 -q:v 2 screenshot_crf_$i.jpg; done
frames direkt anwählen geht auch

achtung: nur runter getippt, nicht getestet

 

[honky-tonk]

ich würde dir handbrake empfehlen. bei RF ~22 +- einstellen und speed medium/slow...mehr musst du eigentlich nicht einstellen. je nach dem wie viel qualität/dateigröße du möchtest RF verringern, je nachdem wieviel zeit du hast den speed langsamer machen, was die qualität erhöht

 

[autoshot]

Tatsächlich benutze ich derzeit myFFmpeg und Handbrake. Die Programme bieten ja beide die Möglichkeit, Hardware-Encoder zu nutzen (hier stünden mir der von meiner RTX 3090 zur Verfügung sowie der vom Apple M1 Max). Sind diese Hardware-Encoder mittlerweile zu gebrauchen oder sollte man lieber weiterhin die CPU rechnen lassen?

 

[madmax2010]

Finde ich eine subjektive Frage. Ja, es gibt visuell minimale unterschiede. Finde ich absolut OK, wenns es drum geht filme / serien platzsparender zu machen.
Andererseits hast du einen 1950X - Dewr schafft auch ein paar 100 FPS

 

[Bob.Dig]

Nimm die CPU, also x265, dazu CRF20 und fertig ist die Laube.

 

[wern001]

Tatsächlich benutze ich derzeit myFFmpeg und Handbrake. Die Programme bieten ja beide die Möglichkeit, Hardware-Encoder zu nutzen (hier stünden mir der von meiner RTX 3090 zur Verfügung sowie der vom Apple M1 Max). Sind diese Hardware-Encoder mittlerweile zu gebrauchen oder sollte man lieber weiterhin die CPU rechnen lassen?

hardware encoder verbessern sich nur wenig. Mit CPU (Wert ca 18-22) und Einstellung auf slow hat man recht.
Wenn das Video krisselig ist evtl. entrauschen auf "leicht"

 

[T00L]

Andererseits hast du einen 1950X - Dewr schafft auch ein paar 100 FPS

HEVC in SW bei slow preset? Niemals.

 

[autoshot]

Andererseits hast du einen 1950X - Dewr schafft auch ein paar 100 FPS

HEVC in SW bei slow preset? Niemals.

Ist mittlerweile sogar ein 5950X. Selbst der schafft aber im Leben keine 100FPS ja.

hardware encoder verbessern sich nur wenig. Mit CPU (Wert ca 18-22) und Einstellung auf slow hat man recht.
Wenn das Video krisselig ist evtl. entrauschen auf "leicht"

Die Hoffnung war eben, dass Apple keine halben Sachen macht und einen brauchbaren Encoder verbaut.

 

[wern001]

Die Hoffnung war eben, dass Apple keine halben Sachen macht und einen brauchbaren Encoder verbaut.

Hardware in in der GPU gemacht und auch die Chips bei Apple sind nun mal von AMD/Nvidia

 

[madmax2010]

die Chips bei Apple sind nun mal von AMD/Nvidia

Der M1 ist eine RISC CPU, die vpn Apple selbst entwickelt wurde. Der encoder kommt wohl aus PowerVR IP

 

[autoshot]

@madmax2010 und der von Apple ist besser als der von AMD/NVIDIA oder schlechter oder ähnlich?

 

[madmax2010]

Kann ich nicht sagen.
Jemand hat das bestimmt mal getestet. Wenn du Googlest und was findest, verlinkt hier gern.
Edit.
Hm laut ffmpeg Hardware acceleration Seite ist der Support nicht im M1 - jedenfalls dort nicht gelistet

 

[autoshot]

Der M1 hat auch keine Encoder, nur der M1 Pro/ Max/ Ultra.

Ergänzung (26. April 2022)

so kannst du dir das durchiterieren:
...

Vielen Dank! Hat nicht direkt funktioniert, aber nach ein bisschen Herumprobieren läufts jetzt

FOR /L  %%a IN (15,1,40) DO ffmpeg -i IMG_3768.MOV -c:v libx265 -vf scale=1920:1080 -crf %%a -c:a copy output_crf_%%a.mp4
FOR /L  %%a IN (15,1,40) DO ffmpeg -ss 00:00:04 -i output_crf_%%a.mp4 -frames:v 1 -q:v 2 screenshot_crf_%%a.jpg

EDIT

Hab das Ganze jetzt mal mit einem 75 MB großen, 11 Sekunden langen UHD-Video getestet.

Auffällig: wenn man das Video von UHD auf FHD (1/4 UHD) konvertieren will macht das eigentlich erst ab CRF 26 oder höher Sinn, da alles unter 26 in größeren Dateien als 1/4 der UHD-Dateigröße (18.8 MB) resultiert. Akzeptable Qualität gibt's bis 29 bzw. 31 (mit ein paar kleineren Abstrichen) und damit 11.6 - 8.6 MB. Die via 2-Pass und fester Bitrate konvertierte Version (8.5 MB) entspricht qualitativ ungefähr CRF 31.

Bei UHD auf UHD ist die Datei sogar erst ab CRF 24 kleiner als das Ausgangsmaterial, wobei ich hier sogar CRF 31 noch als akzeptabel erachten würde bis rauf zu CRF 33 (mit Abstrichen). Die Dateigrößen bewegen sich dann zwischen 25 und 18 MB. Selbst CRF 40 (6 MB) ist noch erstaunlich ansehnlich!

Wens interessiert, sämtliche Dateien können HIER heruntergeladen werden.

 

[Bob.Dig]

@autoshot Letztlich ist dein Test wenig aufschlußreich, weil anscheinend das Quellmaterial schon sehr gut komprimiert war. Wenn dem so ist, kann man natürlich durch Re-komprimieren nichts vernünftiges mehr erreichen.
Sprich, daraus kann man wenig ableiten für andere Quellen, die ggf. deutlich schlechter komprimiert wurden.
Da CRF so was wie ein Qualitätsmerkmal ist, reicht es sich eigentlich zu merken, dass 20 ein "guter" Wert darstellt für x264 und x265. Wenn dein Endfile aber nicht wesentlich kleiner ist, natürlich beim Original bleiben. Das ist halt so und auch völlig in Ordnung. Wenn die Quelle z.B. Youtube ist, da kann man aktuell ohne Verlust nichts "einsparen". Gleiches gilt möglicherweise für das iPhone. Dein Video wird bei mir zumindest auch größer, als es das Original war, von daher, Finger weg.

 

[autoshot]

@Bob.Dig Mir geht's eben drum, möglichst kleine Videodateien zu haben in der Cloud ohne dass die Qualität zu sehr leidet. Die Originaldateien werden nach dem Encoden auf einem NAS und zwei örtlich getrennten externen Festplatten gesichert für den Fall, dass man die irgendwann noch braucht.
Problem ist einfach: selbst wenn die Videos, die das iPhone aufzeichnet, bereits gut komprimiert sind reden wir bei 4K60 HDR immer noch von gut 400 MB pro Minute und das wird dann einfach sehr schnell sehr groß.

Sprich, daraus kann man wenig ableiten für andere Quellen, die ggf. deutlich schlechter komprimiert wurden.

Genau deswegen hab ich den Code hier noch reingestellt, damit das jeder selber testen kann