M1 iMac beschränkt Handbrake auf max 300% wenn man zuviel CPU Last erzeugt hat?

[carsten_h]

dann solltest du ffmpeg nutzen mit meinem neuesten Patch

Das ist dann aber auf der Shell Ebene, oder? Also nichts mit Auswahldialog für Sprachen/Untertitel etc.

 

[lisanet]

Das ist dann aber auf der Shell Ebene, oder?

Yep.

 

[carsten_h]

Yep.

Ich habe es befürchtet.
Mal sehen, ich habe gerade einen Film mit H265 Software in Arbeit und denselben dahinter mit H265 Hardware. Mal sehen was herauskommt.
Danke jedenfalls!

...später
Ausgangslage:
Länge des Films: 1:46 h
Größe: 1920x804

Ergebnis per Software:
Dauer der Konvertierung: 2:44 h
Größe der Datei: 1,21 GB

Ergebnis per videotoolbox:
Dauer der Konvertierung: 0:22 h
Größe der Datei: 4,93 GB

Die Qualität sieht gleich aus, würde ich sagen.

Ich bleibe bei Software, da mir die Dateigröße wichtiger ist. Danke aber für die Hilfe das einmal auszuprobieren!

noch einmal später:

Noch ein zweiter Versuch mit videotoolbox, diesmal mit CQ auf 28:
Dauer der Konvertierung: 0:20 h
Größe der Datei: 1,59 GB

Die Qualität sieht jetzt auf den ersten Blick auch nicht viel schlechter aus.

 

[lisanet]

Die Qualität sieht gleich aus, würde ich sagen.

sag ich doch. Die Ansicht, dass Hardware-Kodierung schlecht wäre ist halt nicht mehr passend.

Hinischtlich der cq. Meinst du mit cq 28 nun die x265-Sklaa, was 100 - 2*28 = 44 videotoolbox entsprechen würde? Da kann man dann schon Unterschiede wahrnehmen, klar.

Jede Videocodierung, egal ob mit Software oder Hardware hat bei cq halt die Eigenheit, dass die Dateigröße nicht vorhersehbar ist und Spitzen in den Bitraten auftreten können. Beim Streaming macht sich das dann mit Bildrucklern bemerkbar. Man kann das verhindern, indem man die Bitrate bei bestimmten Werten kappt. Das kannst du aber nur bei ffmpeg machen.

Du musst auch bedenken, dass "cq" bei x265 eigentlich "crf" bedeutet, was dann heißt, das der Quantizer eben nicht constant bleibt, sondern dass die Qaulität in schnellen Szenen verringert wird, weill bekannt ist, dass man das da nicht bemerkt. So sparen die dort wiederum bitrate. Apple spricht in der Doku nur von "qualitiy" und gibt da einen Wertebereich in % an. Diese Aussage und die Möglichkeit, die Bitratenspitzen zu begrenzen, deuten dann eher auf echt constant quality hin, mit dem Ergebnis, dass schnelle Szenen eben hohe bitraten erzeugen und somit die Dateigröße steigt.

Da solche Spitzen nur recht selten und eher kurzfrisitg und meist bei schnellen Szenenwechseln, hellen Lichtern und Handkameras auftreten, wirst du den Unterschied bei Bitratenbegrenzung faktisch nicht sehen. Streaminganbieter machen das ja auch. Und deren Ergebnisse sind nun echt recht gut.

Hinischtlich der Dateigröße verstehe ich nach wie vor dieses große Streben nach kleinen Dateien echt nicht ganz. Ein Film auf BluRay hat locker 30 GB. Wenn man das nun umkodiert und Dateigrößen von 4 GB erreicht, die visuell gleichwertig sind, warum will man dann noch unbedingt weiter verkleinern auf 2 GB? Wenn ich einen Film _sehe_, dann ist mir doch die visuelle Qualität wichtig und nicht, ob ich 80% oder 90% Größenreduzierung erreicht habe.

 

[carsten_h]

dass schnelle Szenen eben hohe bitraten erzeugen und somit die Dateigröße steigt.

Ah, das könnte sein.
Ich habe jetzt mit mehreren Filmen Experimente gemacht. Der oben genannte sieht z.B. bei cq 24 immer noch total gut aus, aber die Datei ist auf einmal nur noch 1,04 GB groß. Bei 28 ist er 1,19 und bei 40 schon 2,32 groß.
Ein anderer sieht bei 24 und 28 total schrecklich aus (ist auch recht grobkörnig). Erst bei 40 wird er gut. Die Dateigröße schwankt hier nur zwischen 1,19 und 1,58 wobei die Softwarevariante bei 1,8 liegt.
Ich müßte also je Film mehrere Stufen ausprobieren, um zum gewünschten Ergebnis zu kommen. Dann bin ich am Ende doch bei der Zeit, die die Software braucht. Vor allem weiß ich ja nicht im voraus wie groß die Softwarevariante werden würde, um einen Vergleich zu haben.

Sicher ist die Qualität wichtig! Es muß halt beides passen. Ich möchte die alten Filme, die ich habe und in H264 konvertiert habe, von der 10GB Größe herunterbekommen.

Schön, wäre so ein Schalter: "Bring mir das beste, kleinste Ergebnis". Wenn man das irgendwie im voraus bestimmen könnte, wäre das Klasse, bleibt aber wohl ein Traum.

Übrigens sind auch bei der Hardwarevariante (in Handbrake) die Cores (alle) bei ca. 60% und die GPU bei 25%. Die Performance Cores sind aber nur 68°C statt 80°C warm.

 

[oneOeight]

Schön, wäre so ein Schalter: "Bring mir das beste, kleinste Ergebnis". Wenn man das irgendwie im voraus bestimmen könnte, wäre das Klasse, bleibt aber wohl ein Traum.

Das bekommst du wohl nur mit 2 Pass hin.
CRF/CQ ist halt ein Kompromiss, damit man es in einem Durchlauf kodiert.

 

[lisanet]

Vorab: entweder verstehen wir beide uns miss, oder Handbrake hat die Skala verändert. Jeweils für FullHD:
Videotoolbox läuft von 0 (schlecht) bis 100 (gut). Ein Wert für gute Qualität ist um die 60. x265 läuft von 51 (schlecht) bis 0 (gut). Ein Wert von 20 ist gute Qaulität und entspricht videotoolbox 60 (= 100 - 2*20)

Du sprichst immer von cq 28 oder 24. Das sind Werte für x265. Das würde ich nicht für Videotoolbox nehmen. Never.

Es gibt keine Schalter "Bring mir das beste, kleinste Ergenis". Du kannst immer nur in eine Richtung optimieren. Entweder Größe oder Qualität. Nie beides.

Was x265 versucht ist, dass bei schnellen Szenen die Qualität verringert wird, so dass weniger Bits = geringer Größe entsteht. Aber eben die Qualität ist in diesen Szenen schlechter. Darum nennt x265 das ja "crf = constant rate factor" und nicht "cq = constant quality". Ja, Handbrake macht das nicht so deutlich.

Die Doku zu videotoolbox gibt, wie beschrieben eher her, dass es echte "constant quality" ist, also nicht in schnellen Szenen weniger Bits verwendet werden. Ergo: die Datei wird größer als x265.

Fazit: mit cq / crf kannst du die resultierende Dateigröße nicht vorhersagen. Sie hängt einzig und alleine vom Material ab. Dafür hast du eine vorhersagbare Qualität.

Wenn es dir so arg um Dateigröße geht, dann nimm halt nicht cq, sondern gib eine Bitrate vor. Dann kannst du die Dateigröße vorhersagen, aber natürlich nicht die Qualität, weil dann der encoder immer die gleichen Bits verbrät, auch dann wenn weniger Bits ausreichen würden nimmt er die Vorgabe. Das Bild wird da nicht besser. Und bei Szenen, bei denen mehr Bits erforderlich wären nimmt er auch nur die Vorgabe, sprich die Qualität wird schlechter.

Genau diese fixe Bitrate war _früher_ bei Hardwareencodern. Das macht den schlechten Ruf. Aber das ist eben mittlerweile nicht mehr der Fall. Die beherrschen eben auch cq.

Die verwendete Bitrate und damit die Dateigröße kannst du ganz grob im Vergleich ermitteln: Dazu rechnest du wie folgt:

Dateigröße in Bytes = Bitrate in kbps / 8 * Sekunden

oder wenn du das abkürzen willst und lieber Minuten und MB verwendest

Dateigröße in MB = Bitrate in kpbs * Minuten * 0,0075

Bitrate ist dabei die Summe aus Video- und Audiobitrate. Somit kannst du auch ausrechnen, welche Bitrate du vorgeben musst um eine bestimmte Dateigröße zu erreichen:

Wenn du eine 106 Minuten mit 2 GB haben willst und deine Audiospur 448 kbps hat, dann ergibt sich:

Gesamtbitrate = 2000 / (106 * 0,0075) = 2515 kbps - 448 kpbs = 2067 kbps für Video.

Erfahrungsgemäß ist konstanten Bitrate bei FullHD von um die 3000 kpbs für Video schon richtig gut. Netflix z.B. verwendet für FullHD eine durchschnittliche Bitrate von 5000 kbps.

Und zur letzen Rechnung:

x265 verwendet für deren crf Wert (in Handbrake der constant quality Scheiberegler) eine logarithmische Skala in dB. Daher kannst du dort die _Veränderung_ der durchschnittlichen Videobitrate berechnen, wenn du den cq Wert änderst: Eine veränderung um 1 enstpricht 1 dB Änderungen. Somit ergibt sich folgende kleine Tabelle (alles gerundet)

+ 1 -> Faktor 1,1
+ 3 -> Faktor 1,4
+ 6 -> Faktor 2
- 1 -> Faktor 0,9
- 3 -> Faktor 0,7
- 6 -> Faktor 0,5

Mit obiger Formel kannst du also dann die resultierende Dateigröße errechnen, nachdem du den ersten Lauf durch hast.

Für videotoolbox kenne ich die Skala nicht. Aber es ist eben grob / näherungsweise wie geschrieben in etwa analog, nur mit "verdoppelten" Werten, also

+ 6 -> Faktor 1,4
+ 12 -> Faktor 2
- 6 -> Faktor 0,7
- 12 -> Faktor 2

So, jetzt hast du genug Infos und kannst rechnen. Und nun verstehst du vielleicht auch, warum ich immer sage, dass eine pauschale Aussage wie "videotoolbox ist schlecht, x265 ist gut" einfach nicht passt, da es auf viele Parameter ankommt (die Dinge in ffmpeg wie b-frames und GOP-Size habe ich ja noch gar nicht erwähnt. Auch die haben eben Einfluss auf die Größe/Qualität)

Edit:

Noch was zu Hnadbrake:

Ich weiß nicht, ob HandBrake b-frames und GOP-size-Vorgaben in den aktuellen sourcen nutzt. Bei 1.4x war das so. Ich müsste mir da erst die Sourcen zu Handbrake ansehen. Nicht-Nutzen erhöht die Dateigröße.

 

[lisanet]

Das bekommst du wohl nur mit 2 Pass hin.
CRF/CQ ist halt ein Kompromiss, damit man es in einem Durchlauf kodiert.

2-Pass ist eigentlich nur sinnvoll bei vorgegebener "average bitrate", damit im 2.Lauf die Bitrate je nach Szene passend verteilt werden kann, da bei einem Lauf mit average bitrate der encoder die Verteilung der bitrate auf die kommenden frames ja nur schätzen kann.

Aber auch das erfüllt nicht den Wunsch nach "das beste, kleinste Ergebnis", sondern nur "das beste bei der vorgegebenen Größe".

Da die Größe = Bitrate kann man eben die Qualität nicht verlässlich festlegen. Darum versteh ich ja diese Fokusierung auf Dateigröße nicht, wenn man gute Qualität will. Man weiß halt nicht im vornehinein, wieviel Bitrate Szenen benötigen, damit sie gut aussehen.

Ein guter Artikel über diese ganzen Modi ist hier -> https://slhck.info/video/2017/03/01/rate-control.html

 

[oneOeight]

Darum versteh ich ja diese Fokusierung auf Dateigröße nicht, wenn man gute Qualität will.

Ja. Weiß auch nicht, warum er seine Sammlung umkodieren will.
Würde nur die neuen Sachen dann mit x265 machen und den Rest auf x264 lassen.

 

[carsten_h]

Du sprichst immer von cq 28 oder 24. Das sind Werte für x265. Das würde ich nicht für Videotoolbox nehmen. Never.

Das ist in Handbrake hier zu finden:

Es gibt keine Schalter

Schon klar.

So, jetzt hast du genug Infos und kannst rechnen.

Oh, ja, das stimmt. Es ist mir aber zu kompliziert das auszurechnen.

Und nun verstehst du vielleicht auch, warum ich immer sage, dass eine pauschale Aussage wie "videotoolbox ist schlecht, x265 ist gut" einfach nicht passt, da es auf viele Parameter ankommt

Das ist mir durchaus bewußt.

Nur wenn ich eben einen Stapel Filme in einigermaßen kleine Dateien bringen will, ist das richtig viel Aufwand mit den Einstellungen, da ich jeden Film getrennt behandeln muß. MIt der Softwarevariante nehme ich eine Einstellung für alle und lasse das laufen.

warum er seine Sammlung umkodieren will.

Weil 10GB Dateigröße oder 2GB schon einen Unterschied macht. Aber nicht "umkodieren", sondern "neu kodieren".

 

[oneOeight]

Weil 10GB Dateigröße oder 2GB schon einen Unterschied macht.

Ja. Mag sein, aber Speicherplatz ist jetzt nicht so teuer und wenn es vorher 10GB hatte ist 2GB unrealistisch.
So viel effizienter ist x265 jetzt nun auch nicht.
Faktor 5 erreichst du da nicht.
Ein Stillleben in x264 und x265 sollte an sich fast gleich groß sein.

 

[biro21]

@carsten_h Ich bevorzuge ffmpeg im Terminal und da bei videotoolbox ein konstante qualität von 58 (eher verrauschtes Material) bis 65 (rauschfreies Material) und die Qualität passt bei guter Dateigröße und sehr gutem Speed.

Btw 2-pass geht mit videotoolbox nicht.

 

[lisanet]

as ist in Handbrake hier zu finden:

ok, jetzt verstehe ich warum deine Datei so groß wird: Du nimmst HEVC 10bit. Warum? Hast du HDR-Aufnahmen? Mit Nicht-HDR bringt dir das visuell nichts. Nur deutlich größere Dateien.

Und dann hat Handbrake immer noch den Fehler in der Formel, wenn man von einem Preset mit Nicht-Videotoobox auf Videotoolbox umswitcht. Das ist definitv falsch. Glaube es mir. Alleine schon wegen der Optik. Der Regel müsste deutlich weiter rechts stehen, da rechts die bessere Qaulität ist (0 bei x265, 100 bei videotoolbox). Das schreibe ich doch schon die ganze Zeit. Kein Wunder warum videotoolbox einen schlechten Ruf hat, wenn Handbrake das immer noch falsch macht.

Du kannst meine Aussage auch überprüfen: Wenn du x265-preset auf cq 5 einstellst, dann ist das nicht nur ganz rechts, sondern nahezu lossless. Dann stelle auf HEVC um und der Regler springt nach links auf 9 (die 9 deswegen, weil die in ihrer Formal die 1 an der falschen Stelle abziehen, schalte mal einwenig hin und her zwischen videotoolbox und x265 und du siehst deren Rechenfehler und Rundungsdifferenzen). Das ist eine extrem schlechte Qaulität. Ganz besonders eklatant wird das beim Umschalten zwischen x265 (ohne 10 bit) und HEVC 10bit Videotoolbox. Mach das mal ein paar mal.

Und darum: nimm HEVC videotoolbox ohne 10 bit, wenn du kein HDR hast und stell den Regler auf 60.

 

[lisanet]

MIt der Softwarevariante nehme ich eine Einstellung für alle und lasse das laufen.

Das könntest du exakt auch mit videotoolbox machen. Ich habe es getan.

Weil 10GB Dateigröße oder 2GB schon einen Unterschied macht. Aber nicht "umkodieren", sondern "neu kodieren".

und das leigt wie beschrieben daran, dass du offensichtlich videotoolbox 10bit vs. x265 ohne 10bit vergleichst.

Aber, ich sehe schon. Ich schreibe mir die Finger wund und es bringt nichts.

 

[oneOeight]

Seh gerade noch 60 Bilder pro Sekunde.
Ist das in der Quelle so hoch oder hast du das eingestellt?
Eine Bluray hat doch meist 24 BpS.

 

[lisanet]

Seh gerade noch 60 Bilder pro Sekunde.
Ist das in der Quelle so hoch oder hast du das eingestellt?
Eine Bluray hat doch meist 24 BpS.

oh ja, dann doppelt Handbrake solange die frames, bis 60 fps raus kommen. Bei cq hat das dann zur Folge, dass die Dateigröße explodiert. Kein Wunder wenn Carsten mit der Dateigröße nicht zufrieden ist.

@carsten_h Auch wenn's schwer fällt, aber du musst dich echt noch etwas mit den ganzen Parametern befassen. Sonst sind deine encodings nicht so sonderlich sinnvoll.

Edit:

... ich weiß, Videocodierung ist kein leichtes Geschäft. Aber wenn du tatsächlich 60 fps aus einer BluRay mit 23,976 fps machen willst, dann nimm lieber 59.94, dann bleibst du wenigstens in der NTSC-Norm und stelle auf jeden Fall "Konstante Bildfrequenz" ein. Sonst rechnet Handbrake ein klein wenig anders um auf die Zielrate zu kommen, was dann dazu führt, dass du definitiv nicht die gewünschten fps erhälst.

 

[carsten_h]

Du nimmst HEVC 10bit. Warum?

Das war nur ein Test, um zu sehen, was sich dort ändert. Bei den anderen werden die normalen 8bit genommen, keine Angst.

Ich schreibe mir die Finger wund und es bringt nichts.

Doch sicher bringt das etwas!

Wenn du x265-preset auf cq 5 einstellst, dann ist das nicht nur ganz rechts, sondern nahezu lossless. Dann stelle auf HEVC um und der Regler springt nach links auf 9 (die 9 deswegen, weil die in ihrer Formal die 1 an der falschen Stelle abziehen, schalte mal einwenig hin und her zwischen videotoolbox und x265 und du siehst deren Rechenfehler und Rundungsdifferenzen).

Das hier wird bei der Standard-Einstellung für Software dort angezeigt:

Dort steht also RF, was auch immer das bedeutet. Ich kenne mich damit nicht die Bohne aus!
Wenn man auf H.265 (Videotoolbox) umschaltet wird daraus CQ 46. Dann zurück steht dort RF 23, dann CQ 44, also ganz wie Du geschrieben hast.

Ist das in der Quelle so hoch oder hast du das eingestellt?

In der Quelle sind es 23,966025 und das ist auch das, was hinten heraus kommt. Sowohl bei Software als auch bei Hardware. Genau wie als Größe 3840x2160 eingestellt ist, er aber das nimmt, was von der Quelle kommt. Also 480p rein->480p raus.

oh ja, dann doppelt Handbrake solange die frames, bis 60 fps raus kommen.

Nein, es kommen genau 23,976025 Hz dabei heraus. Das bedeutet nur, daß er das nehmen soll, was von der Quelle kommt. Da wird nichts umgeändert. So viel habe ich schon verstanden.

aber du musst dich echt noch etwas mit den ganzen Parametern befassen. Sonst sind deine encodings nicht so sonderlich sinnvoll.

Also mit der Standard Einstellung "Apple 2160p60 4K HEVC Surround" kommt schon sinnvolles heraus. Ich wollte nur mal sehen, ob man mit der Hardware des M1 das auch sinnvoll und einfach so hinbekommt wie ich das möchte. Aber das ist ja leider nicht so. Es geht, ist aber eben nicht mit einer Standardeinstellung erledigt.

 

[lisanet]

Wenn man auf H.265 (Videotoolbox) umschaltet wird daraus CQ 46. Dann zurück steht dort RF 23, dann CQ 44, also ganz wie Du geschrieben hast.

nein, das habe ich eben nicht beschrieben.

Diese Umrechnung von Handbrake ist falsch! Ich habe geschrieben, dass die korrekte Formel lautet: videotoolbox = 100 - 2*x265, also hier 100 - 2*23 = 54! Nicht 46. Handbrake rechnet falsch um!

 

[lisanet]

Aber das ist ja leider nicht so. Es geht, ist aber eben nicht mit einer Standardeinstellung erledigt.

Doch das geht schon. Die "Standardeinstellung" von Handbrake ist falsch. Ist das wirklich so schwer zu verstehen? Aber lass es sein. Ich weiß, was ich seit kodiere, mit welchem Erfolg und kann das vergleichen, ich weiß was ich für Code und Patches schreibe und wie die funktionieren.

Du hast dein Vorurteil, willst mich offensichtlich nicht verstehen oder versuchen das nachzuvollziehen, was ich dir an Lösungsmöglichkeiten anbiete. Okay. musst du nicht tun. Bleib bei deinen Presets für x265.

 

[lisanet]

Btw 2-pass geht mit videotoolbox nicht.

... würde bei cq auch keinen Sinn ergeben. Die API von Videotoolbox bietet durchaus eine 2-Pass-Kodierung an.