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

autoshot

Admiral
Registriert
Juni 2007
Beiträge
8.727
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
 
autoshot schrieb:
zwar via 2-Pass Encoding bei vorgegebener Bitrate.
Das kann doch auch schlecht werden bei schlecht gewählter vorgegebener Bitrate und auch encoding Parameter.

autoshot schrieb:
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.

autoshot schrieb:
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.
 
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
 
  • Gefällt mir
Reaktionen: autoshot
motorazrv3 schrieb:
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...

motorazrv3 schrieb:
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 :(
 
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
 
  • Gefällt mir
Reaktionen: autoshot
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
 
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?
 
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
 
Nimm die CPU, also x265, dazu CRF20 und fertig ist die Laube.
 
  • Gefällt mir
Reaktionen: 0ssi
autoshot schrieb:
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"
 
madmax2010 schrieb:
Andererseits hast du einen 1950X - Dewr schafft auch ein paar 100 FPS
T00L schrieb:
HEVC in SW bei slow preset? Niemals.
Ist mittlerweile sogar ein 5950X. Selbst der schafft aber im Leben keine 100FPS ja.

wern001 schrieb:
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.
 
autoshot schrieb:
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 und der von Apple ist besser als der von AMD/NVIDIA oder schlechter oder ähnlich?
 
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
 
Der M1 hat auch keine Encoder, nur der M1 Pro/ Max/ Ultra.
Ergänzung ()

madmax2010 schrieb:
so kannst du dir das durchiterieren:
...
Vielen Dank! Hat nicht direkt funktioniert, aber nach ein bisschen Herumprobieren läufts jetzt :)

Code:
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.
 
Zuletzt bearbeitet:
@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.
 
Zuletzt bearbeitet:
@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ß.

Bob.Dig schrieb:
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 :)
 

Ähnliche Themen

Antworten
14
Aufrufe
39.841
Zurück
Oben