Handbrake und Dauer der Umwandlung

[Dagobah]

Hallo zusammen,

ich bin derzeit auch am Testen was Komprimierung mit Handbrake angeht. Ich dachte auch, ich hätte inzwischen einen guten Kompromiss gefunden. Aber vielleicht habt ihr noch ein paar Tips.

Ich besitze einen i5 6500 und 16GB Ram, Grafikkarte ist (noch) nicht vorhanden.

Komprimieren will ich Actionfilme ins mkv - Format, als Einstellungen habe ich H264, Level 4.0, RF19, Preset auf very slow gewählt. Auflösung ist 1280x720 (oder entsprechend 1280x544). Mit zwei Tonspuren (AC3 mit 384kb Stereo und 640kb 5.1) und Untertiteln komme ich für einen 2 Std. Film so auf ca. 3GB bei einer Rechendauer von etwas über 3 Stunden.

Mit der Rechendauer bin ich zufrieden und mit der Qualität eigentlich auch. An einigen Stellen (nachts in einer Höhle mit Lagerfeuer) bemerkt man aber doch eine Klötzchenbildung (könnte ich zur Not aber mit leben).

Durch diesen Thread bin ich jetzt auf H265 aufmerksam geworden ==> Geschwindigkeit = 2,4 fps (auf Preset very slow), also eine Rechendauer von über 20 Stunden. Dies wäre mir doch etwas zu viel.

Ich werde jetzt mal etwas weiter testen an einigen ausgewählten Stellen und schauen, was es so bringt.

Jetzt meine Frage an Euch: Welche Einstellungen benutzt ihr so? Nehmt ihr h264 oder h265 und welche Qualitystufe wählt ihr? Ich bin mir da manchmal nicht sicher, ob ich noch einen Unterschied sehe oder ob ich ihn mir nur einbilde.

 

[Bagbag]

Was ist dir denn Wichtig? Du musst abwägen zwischen Zeit, Qualität und Dateigröße.

Ich selbst nutze x264, da mir x265 zu lahm ist und mir die Qualität bei HEVC_NVENC "nicht ausreichend" ist (siehe vorheriger Post), beziehungsweise ich weiß, dass ich in für mich akzeptabler Zeit eine bessere Qualität mit x264 erreiche.

Presets langsamer als slow sind nicht zu empfehlen und selbst slow ist i.d.R. absolut nicht nötig. Der Qualität/Dateigrößen Vorteil steht dabei in keiner Relation zur zusätzlichen Zeit, die dabei benötigt wird.

Ich habe schon viele, viele Tests gemacht und bin dabei für mich auf folgende Parameter gekommen (für 1080p):

ffmpeg [...] -c:v libx264 -crf 18 -preset faster -c:a aac -b:a 192k

Mir ist die Dateigröße dabei i.d.R. nicht wirklich wichtig. Falls es das mal sein sollte, nehme ich das Preset medium/slow und gehe mit dem CRF ein wenig hoch.


http://www.videoquality.pl/preset-settings-x264-quality-compression-speed-test/
https://mattgadient.com/2014/01/06/handbrake-rf-slower-speeds-craziness/
http://blogs.motokado.com/yoshi/2011/06/25/comparison-of-x264-presets/

 

[Dicht_ins_Licht]

So, eine Datei ist jetzt endlich fertig. Qualität schaut sauber aus.
Vom technischen Unterschied her im Vergleich zu h.264: Dateigrösse 8.84GB vs. 14.2GB; 12.3MB/s Bitrate vs. 18.1MB/s

 

[Bagbag]

Und wie hast du es jetzt kodiert?

 

[Dicht_ins_Licht]

So wie im ersten Thread angegeben.

 

[yaegi]

Bitte beschuldige andere nicht des Halbwissen, wenn deines nicht mal Viertelwissen erreicht.

da muss ich ebenfalls wiedersprechen! und sehe das genauso wie "derbe".

kann ja sein, dass du mehr weißt als alle andren. allerdings scheinen deine augen nicht zu funktionieren. außerdem lasse ich mich von deinen "super encodings" nicht veräppeln! du hast die bitrate nämlich absichtlich so extremst schlecht gewählt, dass du ein sehr schlechtes und ein extrem schlechtes ergebnis bekommen hast. klar dass der nvencoder ganz untem im keller nochmals viel schlechter rendert.

in sinnvollen bitraten allerdings sieht man qualitativ absolut keinen unterschied! und ja ich kann das selbst testen.

 

[Bagbag]

allerdings scheinen deine augen nicht zu funktionieren.

Das musst du mir erklären. Du findest das NVENC Encoding also besser?

außerdem lasse ich mich von deinen "super encodings" nicht veräppeln! du hast die bitrate nämlich absichtlich so extremst schlecht gewählt, dass du ein sehr schlechtes und ein extrem schlechtes ergebnis bekommen hast.

Ich wollte damit die technische Unterlegenheit von NVENC aufzeigen, die es laut derbe ja nicht geben würde. Veräppeln möchte ich auch niemand - schließlich habe ich die Parameter nicht für mich behalten.

klar dass der nvencoder ganz untem im keller nochmals viel schlechter rendert.

Ach, und x265 kann bei niedrigen Bitraten zaubern? Dort waren die Bitraten genauso im Keller.

in sinnvollen bitraten allerdings sieht man qualitativ absolut keinen unterschied!

Was ist sind denn für dich sinnvolle Bitraten? Und nur mal so als Info zum Rande: Bei YouTube liegt die Bitrate oft auch nur im Bereich von ~3 Mbit/s. Und dort wird u.A. noch h264 genutzt.

So "extrem schlecht" sind die Parameter also nicht - zumindest ist sie für einen gewaltigen Teil der Videos die Weltweit angeschaut werden fast ausreichend.

Der Hauptgrund weshalb das Video mit den Quallen so schlecht aussieht ist einfach, weil die Szene für einen Encoder aufgrund der vielen kleinen Partikeln eine sehr schwere ist - für NVENC genauso wie für x265.

Beweis: https://batrick.de/encodetest/ghosttown.mp4

ffmpeg -ss 24 -t 10 -i ghosttown4k.mkv -vf scale=-1:1080 -c:v libx265 -crf 25 -c:a copy ghosttown.mp4

Das Video hat eine Durchschnittsbitrate von gerade mal 1027 Kbit/s, also noch deutlich, deutlich weiter "im Keller" und sieht dafür sehr, sehr gut aus! (zumindest für meine nicht funktionierenden Augen)

Edit: hier habe ich nicht mal preset slow genutzt!

Ergänzung (19. Januar 2017)

Weiteres:

Quelle: https://www.youtube.com/watch?v=FForvEQevKI in 5K.
Das 5K Video habe ich mit CRF 10 (also praktisch lossless) und lanczos als Algorithmus runterskaliert.

ffmpeg -i mara.mp4 -c:v libx265 -b:v 5000k -c:a copy libx265.mp4
ffmpeg -i mara.mp4 -c:v hevc_nvenc -b:v 5000k -c:a copy hevc_nvenc.mp4

Ergebnis:
libx265
hevc_nvenc

Man schaue sich das Ohr oben rechts an, zwischen den Ohren..

Mit 5 Mbit/s nun hoffentlich keine Bitraten im Keller/extremst schlecht, sondern sinnvoll - auch angesichts der Tatsache, dass im Video nicht viel Bewegung ist.

-> x265 hat deutlich mehr Details. Und dabei hat es noch nicht mal seine CRF Fähigkeit nutzen dürfen, womit x265 noch besser dastehen würde.


Also bitte, sag mir nicht

in sinnvollen bitraten allerdings sieht man qualitativ absolut keinen unterschied!

oder verrate mir was sinnvolle Bitraten für dich sind.

 

[kumpert]

-> x265 hat deutlich mehr Details. Und dabei hat es noch nicht mal seine CRF Fähigkeit nutzen dürfen, womit x265 noch besser dastehen würde.

Du gewährst NVENC allerdings auch keinen 2Pass, wodurch NVENC auch besser darstehen würde und bezogen auf die Geschwindigkeit wäre es auch nur so wirklich sinnvoll. Die GPU wäre immernoch deutlich schneller, da du aber in deine Betrachtungen die Zeit nicht mit rein nimmst, wäre es sinnvoller

Schick mir mal das runterskalierte Ausgangsmaterial. Würde mich mal interessieren, ob das mit den gleichen Einstellungen besser auf der 1070 aussieht.

Machen wir das ganze mit "schlechteren" Parametern, so würde sich der Zeitunterschied und auch die Qualität im Verhältnis zugunsten von libx265 verschieben.

So funktioniert das nicht wirklich. Welche Parameter willst du den schlechter wählen? Senkst du CRF steigt sowohl die Qualität als auch die Bitrate und diese steigt mit dem CRF exponential an, während die Encoding Zeit im Mittel wohl nur linear sinkt. Wenn Geschwindigkeit und Qualität gleichwertig gewichtet werden, wäre dies also eine schlechte Entscheidung. Änderst du das Preset nimmst du NVENC den 2Pass. Also würde nur eine Änderung des Presets von x265 Sinn machen, da du wohl schneller an Zeit gewinnen wirst als an Qualität verlieren. Allerdings verschiebt sich dann die Qualität zugunsten von NVENC.

Wenn ich am Wochenende zuhause bin werde ich Jelly auch nochmal kodieren. Welches hast du da genommen? Es sind zwei mit 180mbps online. Deine Version heißt ja bereits Jelly.mp4 obwohl es ursprünglich eine mkv ist. So macht man auch nicht wirklich nachvollziehbare Vergleiche.

Genauso warum ein reencode vom Youtube Video? Statt einem einfachen Resize?

 

[Bagbag]

Du gewährst NVENC allerdings auch keinen 2Pass

Als ich NVENC mit -preset slow nutze, hat es sich stets mehr als die Eingestellten 5000 Kbit/s gegönnt - auch mit Parametern wie -maxrate.
Im Gegenzug dafür habe ich aber x265 auch kein CRF nutzen lassen.

Die GPU wäre immernoch deutlich schneller, da du aber in deine Betrachtungen die Zeit nicht mit rein nimmst, wäre es sinnvoller

Ja, habe ich in meinem ersten Post hier im Thread aber auch erwähnt.

Schick mir mal das runterskalierte Ausgangsmaterial. Würde mich mal interessieren, ob das mit den gleichen Einstellungen besser auf der 1070 aussieht.

Das würde mich auch interessieren: https://batrick.de/encodetest/mara.mp4

So funktioniert das nicht wirklich. Welche Parameter willst du den schlechter wählen? Senkst du CRF steigt sowohl die Qualität als auch die Bitrate und diese steigt mit dem CRF exponential an, während die Encoding Zeit im Mittel wohl nur linear sinkt. Wenn Geschwindigkeit und Qualität gleichwertig gewichtet werden, wäre dies also eine schlechte Entscheidung. Änderst du das Preset nimmst du NVENC den 2Pass. Also würde nur eine Änderung des Presets von x265 Sinn machen, da du wohl schneller an Zeit gewinnen wirst als an Qualität verlieren. Allerdings verschiebt sich dann die Qualität zugunsten von NVENC.

Die Geschwindigkeit von hevc_nvenc war bei mir immer unabhängig vom Preset bei 5-6 fach. Da ich bei dem Encoding, von dem du das Zitat her hast bereits "slow" (also 2pass) nutze, wäre sowohl bei x265 (praktisch) und nvenc nur schnellere Presets möglich. Und wie du selbst bereits sagtest, würde x265 da mehr Geschwindigkeit gewinnen, als Qualität verlieren. NVENC dagegen würde nur an Qualität verlieren (da - zumindest bei meinen Tests - die Geschwindigkeit immer gleich blieb).

Ergo -> x265 gewinnt an Effizienz, während nvenc verliert.

Wenn ich am Wochenende zuhause bin werde ich Jelly auch nochmal kodieren. Welches hast du da genommen? Es sind zwei mit 180mbps online. Deine Version heißt ja bereits Jelly.mp4 obwohl es ursprünglich eine mkv ist. So macht man auch nicht wirklich nachvollziehbare Vergleiche.

Genauso warum ein reencode vom Youtube Video? Statt einem einfachen Resize?

Das Jellyvideo war http://jell.yfish.us/media/jellyfish-180-mbps-4k-uhd-h264.mkv

Warum ich es neu kodiert habe, gute Frage. Das habe ich mich im nachhinein auch gefragt. Da es ja aber nur um einen Vergleich zwischen x265 und hevc_nvenc ging und die Qualität der Quelle wegen CRF 10 (und cpu-encoding ) sehr gut war, war mir das dann egal.

 

[Dagobah]

Was ist dir denn Wichtig? Du musst abwägen zwischen Zeit, Qualität und Dateigröße.

Ich selbst nutze x264, da mir x265 zu lahm ist und mir die Qualität bei HEVC_NVENC "nicht ausreichend" ist (siehe vorheriger Post), beziehungsweise ich weiß, dass ich in für mich akzeptabler Zeit eine bessere Qualität mit x264 erreiche.

Presets langsamer als slow sind nicht zu empfehlen und selbst slow ist i.d.R. absolut nicht nötig. Der Qualität/Dateigrößen Vorteil steht dabei in keiner Relation zur zusätzlichen Zeit, die dabei benötigt wird.

Wichtig ist mir die Dateigröße, ohne dabei eine gewisse Qualität zu unterschreiten (ich weiß, diese Qualität muß ich erst noch selbst für mich bestimmen). Die Zeit ist absolut zweitrangig, wobei 20 Stunden wohl etwas übertrieben wären. Aber mit den entsprechenden Presets werde ich das wohl hinbekommen. An den Audiospuren werde ich wohl auch noch etwas sparen können, mal schauen.

Nachteil bei x265 wäre, das mein Receiver den nicht per USB wiedergeben kann, aber ich schaue eigentlich eh nür über den PC. x265 dauert zwar länger, aber die Kompression ist schon nicht schlecht. Ich werde demnächst mal weiter testen und vergleichen.

 

[Bagbag]

Dann würde ich, sofern du eine halbwegs potente CPU hast folgendes nutzen:

ffmpeg -i input.mkv c:v libx265 -preset faster -crf 18~26 output.mkv

Mein i5-3450 schaffte bei einem Test mit FHD Material von 5s Dauer folgende Ergebnisse:

veryslow:	0.014x	352s	7.54MB
slower:		0.021x	232s	7.65MB
slow:		0.083x	60s	7.46MB
medium:		0.186x	27s	7.39MB
fast:		0.267x	19s	6.23MB
faster:		0.312x	16s	6.17MB

Von veryslow (wie du es hattest) zu faster etwa Faktor 22. Überraschend finde ich, dass die Dateigröße sogar abnimmt, Qualität war jedes mal - wegen CRF wie erwartet - immer gleich.
Bleibt die Frage in wie weit man einen Test mit einem 5 Sekunden Video auf eines mit 2 Stunden übertragen kann. Auf mehr hatte ich aber wegen der enormen Langsamkeit keine Lust.

 

[kumpert]

Ergo -> x265 gewinnt an Effizienz, während nvenc verliert.

So wäre die Aussage auch richtig gewesen. x265 gewinnt an Effizienz, aber die Qualität verschiebt sich dabei nicht zu gunsten von x265.

Von veryslow (wie du es hattest) zu faster etwa Faktor 22. Überraschend finde ich, dass die Dateigröße sogar abnimmt, Qualität war jedes mal - wegen CRF wie erwartet - immer gleich.

CRF ist ungleich Qualität. Müsstest mal ne Metric drüberlaufen lassen, dann würdest dies auch sehen. Hier sonst mal ein Bild dazu.


Daher kommt auch das Phänomen mit der steigenden Bitrate, da du auch an Qualität gewinnst. Das war in x264 aber auch schon so. Generell soll es etwa so aussehen:



Ich setz mich gleich mal ans encoden und editiere dann.

 

[Bagbag]

So wäre die Aussage auch richtig gewesen. x265 gewinnt an Effizienz, aber die Qualität verschiebt sich dabei nicht zu gunsten von x265.

Genau das habe ich doch schon zuvor gesagt.

Machen wir das ganze mit "schlechteren" Parametern, so würde sich der Zeitunterschied und auch die Qualität im Verhältnis zugunsten von libx265 verschieben.

CRF ist ungleich Qualität.

Sondern?

Wir definieren vor dem Encoding ein Qualitätsniveau, das vom Encoder eingehalten wird [...] Mit Qualität ist hier die visuelle Qualität gemeint, die wir beim Anschauen wahrnehmen. [...] Nur die neueren Encoder wie x264 oder x265 unterstützen einen echten Qualitätsmodus. Er heißt dort CRF (Constant Rate Factor).

CRF berücksichtigt also zu einem gewissen Grad, wie das menschliche Auge arbeitet

https://encodingwissen.de/codecs/encodingmethoden/#pass-konstante-qualitat
https://encodingwissen.de/codecs/x264/technik/#quantizer-und-constant-rate-factor-crf

Daher kommt auch das Phänomen mit der steigenden Bitrate, da du auch an Qualität gewinnst.

CRF war aber immer gleich. Einzig der Preset habe ich verändert. Und da hätte ich erwartet, dass slower eine geringer Bitrate braucht als faster.
In der Regel ist das auch so, aber bei dem Video mit dem ich getestet habe aus irgendeinem Grunde nicht.

 

[kumpert]

Genau das habe ich doch schon zuvor gesagt.

Deine Formulierung legt nahe, dass du Qualität und Zeitunterschied getrennt mit NVENC vergleichst.

Sondern?

https://encodingwissen.de/codecs/encodingmethoden/#pass-konstante-qualitat
https://encodingwissen.de/codecs/x264/technik/#quantizer-und-constant-rate-factor-crf


CRF war aber immer gleich. Einzig der Preset habe ich verändert. Und da hätte ich erwartet, dass slower eine geringer Bitrate braucht als faster.
In der Regel ist das auch so, aber bei dem Video mit dem ich getestet habe aus irgendeinem Grunde nicht.

Steht CRF für "Contant Quality"? In deinem Link wird nebenbei auch erwähnt, dass dieser intern abgeändert wird und das wird durch das preset beeinflusst.

Here's the explanation for what the OP is observing, the slower presets make use of various psycho-visual enhancements that faster presets do not and as you get to the slower settings the psycho-visual settings get more aggressive as well. If you read up on x265's psycho-visual algorithms, and x264's for that matter, you find that various settings will actually pump up the bit rate in CRF mode in order to avoid artifacts.

Sonst noch mal hier als Beispiel:
http://i.cubeupload.com/KXP9LR.png
http://i.cubeupload.com/sa4w1W.png

Ist beides CRF23 und ja das Video vom besseren Bild ist größer.



Sonst noch hier mein Mara Encode
Mara:
http://i.cubeupload.com/jJaMqh.png
http://i.cubeupload.com/rL04Ib.png
Das ist der beste Mara NVENC Encode von mir:
http://i.cubeupload.com/65dTsn.png

Das einzige was mich irritiert ist das meine Frames in beiden Fällen dunkler sind als deine. Wie gibst du die aus? Ich lass ffmpeg einfach alle Frames mit -r ausgeben. Der Qualitätsunterschied ist aber sonst genauso groß, wie in deinen Frames.


Beim Jelly sehe ich gerade, dass du wieder nicht angegeben hast womit der resize stattfand, da deine Frames keine 4k Auflösung haben, das Video allerdings schon.

 

[Bagbag]

Steht CRF für "Contant Quality"? In deinem Link wird nebenbei auch erwähnt, dass dieser intern abgeändert wird und das wird durch das preset beeinflusst.

Es steht für "Constant Rate Factor" - das weißt du sicher. Darfst du aber auch gerne "Constant Quality" nennen. Dass der CRF intern das ganze in einen passenden QP "umwandelt" war ich mir bewusst. Was genau die "low-level" Parameter sind, also das was die Presets einstellen, habe ich mir dagegen noch nicht näher angeschaut.

Sonst noch mal hier als Beispiel:
http://i.cubeupload.com/KXP9LR.png
http://i.cubeupload.com/sa4w1W.png

Ist beides CRF23 und ja das Video vom besseren Bild ist größer.

Und wie sahen deine FFmpeg Parameter dafür aus?

Wie gibst du die aus?

Während dem Anschauen der Videos in MPC-HC einfach das aktuelle Frame gespeichert.

Beim Jelly sehe ich gerade, dass du wieder nicht angegeben hast womit der resize stattfand, da deine Frames keine 4k Auflösung haben, das Video allerdings schon.

So wie bei dem anderen auch. Rekodiert mit "-vf scale=-1:1080 -crf 10".

Aber viel wichtiger als das "wie beim skalieren" (da alle Tests dann das gleiche verkleinerte Video nutzten...), wäre das "wie beim (Haupt)Kodieren" - wie sind die von dir genutzten Parameter?

Mara:
http://i.cubeupload.com/jJaMqh.png
http://i.cubeupload.com/rL04Ib.png
Das ist der beste Mara NVENC Encode von mir:
http://i.cubeupload.com/65dTsn.png

Ist das alles NVENC? Falls ja: ich finde Bild 2 am besten.


Edit:

Teste mal bitte

./ffmpeg.exe -i mara.mp4 -c:v hevc_nvenc -b:v 1M -preset slow -c:a copy out.mp4

sodass wir GTX 970 mit der 1070 vergleichen können.


Hier meines: https://batrick.de/encodetest/elefant/hevc-nvenc_1000k_preset-slow.png
und noch hevc_nvenc mit libx265 ersetzt: https://batrick.de/encodetest/elefant/libx265_1000k_preset-slow.png

 

[kumpert]

Und wie sahen deine FFmpeg Parameter dafür aus?

Einfach nur CRF 23 und veryslow bzw ultrafast.

Aber viel wichtiger als das "wie beim skalieren" (da alle Tests dann das gleiche verkleinerte Video nutzten...), wäre das "wie beim (Haupt)Kodieren" - wie sind die von dir genutzten Parameter?

Logischerweise benutze ich das was du angegeben hast.

Ist das alles NVENC? Falls ja: ich finde Bild 2 am besten.

Die ersten beiden sind Mara mit deinen Einstellungen, sprich einmal NVENC und x265. Das dritte ist wieder ein NVENC Encode mit anderen Parametern, wollte einfach nur sehen was er sich an Bitrate nimmt. Waren jetzt 12M.

Edit:

Teste mal bitte

./ffmpeg.exe -i mara.mp4 -c:v hevc_nvenc -b:v 1M -preset slow -c:a copy out.mp4

sodass wir GTX 970 mit der 1070 vergleichen können.

http://i.cubeupload.com/wMS03R.png

Allerdings hätte es auch so aussehen können, dazu muss man aber natürlich ein paar Einstellungen ändern:
http://i.cubeupload.com/pIz3W1.png
Die Bitrate ist hier auch kleiner. Wirst ja auch ne Meldung bekommen, dass die Kontrollen setzen sollst. Die habe ich mit qmax=41 eingegrenzt. Von selbst benutzt er noch einige darüber, ohne wirklich Einsparungen zu machen. Man müsste wohl überprüfen, ob nur der Frame besser ist oder das ganze Video.

edit: Hab jetzt SSIM drüber laufen lassen. Im Mittel ist das 1M Video besser, einige Frames sind aber durch meine Einstellung besser geworden, da der Encoder sonst bis zu 44 hochgeht.

 

[Humptidumpti]

Blu-Ray -> NAS -> Kopierschutz -> No No

closed