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

Okay. Die Hardwarebeschleunigung war halt ursprünglich dazu da, überhaupt in Bereiche von Echtzeit zu kommen...
Berichte, dass das umwandeln eines UHD-Filmes mehrere tage dauert sind aber schon länger nicht mehr aufgetaucht...

Ich gehe ja auch davon aus das das ganze mittlerweiler Flexibler und genauer geworden ist.
 
Noch ein konkretes Beispiel: Kodierung eines Full-HD-Videos, crop auf 1920x832, Dauer 1h 42 min

- mit x265 superfast, crf 20 -> ca 50 fps, 1,97 GB
- mit hevc-VT, cq 60, b-pyramid -> ca 250 fps, 2,42 GB
- mit hevc-VT, cq 60, b-pyramid, neue speed option -> ca. 420 fps 2,46 GB

visuell keine Unterschiede.
Hardwareencoder VT: ca. 25% größer (Dateigröße) bei vermeintlich vergleichbarer Qualität.
Das ist für _mich_ nicht gleichwertig (aber um einiges besser als ich erwartet hätte).

Die Software und entsprechendes Material habe ich hier zusammen getragen gehabt (sorry im vorraus, dass der Eintrag noch immer nicht fertig gestellt ist - das Ganze nimmt recht viel Zeit in Anspruch):
Der Codec Beitrag
Danke für den Link und Beitrag.
 
Das ist für _mich_ nicht gleichwertig (aber um einiges besser als ich erwartet hätte).

... ich schreibe ja immer von _visuell_ gleichwertig. Du beziehst "gleichwertig" auch auf die Dateigröße. Kannst du ja machen, aber dann reden wir halt von unterschiedlichen Dingen.
 
Hallo an alle, bin neu hier.
Ich habe auch so meine Probleme mit Handbrake. Also es läuft alles soweit OK.
habe aber mal ein Test gemacht.
Wenn ich auf meinen alten i7 MBPr 15" late 2013 /16 GB bei 264 mit VTB die gleichen Einstellungen verwende wie auf meinen M1 iMac 8Core GPU / 16 GB Ram / 1 TB SSD. ist der alte i7 sogar etwas flotter, solange er nicht warm wird. Dann ändert es sich natürlich. Puste ich den dann mit den Ventilator an, ist er wieder vorne. Komisch, dass der überhaupt etwas mit VTB unterstützt. Zwar nur bei 264 aber naja.

Wenn ich jedoch ohne VTB bei gleichen Einstellungen arbeiten lasse, ist der M1 aber deutlich vorne. Ca. 2-3 fach mindestens.

Nur komisch, dass es bei VTB eigentlich eher andersrum ist.
 
Das ist aber nicht normal. Ohne VTB ist der M1 deutlich langsamer als mit VTB.
 
Hallo, meine da den Vergleich zum i7. VTB ist ca. 2-3 x Scheller wie ohne. Oder auch sehr viel langsamer, wenn man den Geschwindigkeitsregler ganz weit nach rechts schiebt. Placebo habe ich da noch nicht getestet.
 
Du musst eine native ARM-Version nutzen. Ein Intel-Binary via Rosetta nutzt den Hardware-Encoder des M1 nicht voll aus, wenn überhaupt.
 
Die Videotoolbox sollte man besser nicht nutzen (allgemein, nicht nur beim M1), wenn einem Qualität und Dateigröße wichtig ist.
Beim M1 scheint der Hardware-Encoder sogar richtig schlecht zu sein. Zwar super schnell aber bis hin zu grauenhaft hinsichtlich Qualität/Dateigröße.

Handbrake zu nutzen ist richtig. Aber auf der CPU ohne die Videotoolbox. Es sei denn für ein Draft-Video oder so.

Videotoolbox ist gut für Streaming und um in Benchmarks zu glänzen (beim Ignorieren der Aspekte Qualität und Dateigröße).

Beispiel:
"Seeing exact same thing. I haven't compared the VT vs x265 quality yet extensively but eye test, the VT version had to be encoded at 8K+ BR to yield comparable quality to x265 which was closer to 2K BR. And of course the resulting 9GB file vs 2.3GB file."
https://forums.macrumors.com/threads/mac-mini-m1-h-265-encoding.2269815/
Das kann ich bestätigen, allerdings nicht auf dem M1 sondern auf einem AMD-Ryzen mit GTX1080. CPU Renderding dauerte doppelt so lange wie über die Grafikkarte, allerdings war die Datei auch deutlich größer. Deswegen habe ich dann wieder über den CPU gerendert, die 2 - 3 Minuten mehr pro Film ist mir dann wurscht.
 
Hallo, ich nutze die ARM-Version. Also die M1 optimierte.
und wie läuft es mit HEVC statt h264?

videotoolbox bedeutet ja nicht nur Apple-Hardware, sondern nutzt auch Hardware-Encoder (falls vorhanden) auf Intels. Allerdings ist die Qualität beim M1 HEVC deutlich besser.

Probiere auch mal ffmpeg.
 
Danke. Muss mal schauen wo ich das überhaupt finde. Bin noch Neuling was Handbrake angeht. hatte sonnst immer mit iVI gearbeitet.

Wobei ich bei Handbrake aber bei Videoencoder nur H265 und H264 in etlichen Ausführungen habe und MPEG 2 / 4.
Von HEVC und ffmpeg etc. finde ich leider nichts. Nur in den Voreinstellungen gibt es z.B. nen Apple HEVC Surround. Aber der läuft auch auf H265.

Oder suche ich noch falsch?
 
Zuletzt bearbeitet:
Danke, du meinst also ich soll HEVC H265 dann mit oder ohne VTB nutzen bzw. testen?
Ja, einmal mit x265 als Encoder und dann das Videotoolbox Preset mit ähnlichen Einstellungen.
Nimm aber was mit viel Schwarz und viel Bewegung.
Die Matrix Teil irgendwas Szene wo die Krakenviecher ausschwärmen in Hunderten oder so.
 
Ja, einmal mit x265 als Encoder und dann das Videotoolbox Preset mit ähnlichen Einstellungen.
Nimm aber was mit viel Schwarz und viel Bewegung.
Die Matrix Teil irgendwas Szene wo die Krakenviecher ausschwärmen in Hunderten oder so.a

... als Anhaltspunkt: x265 mit crf 20 = h265 VT mit 60, oder allgemein: VT = 100 - 2*

Und die schwarzen Bereiche oder andere dunkle eher gleichförmige Bereiche sind in x265 eher früher mit Blockartefakten, als in videotoolbox. x265 bietet verschieden Modi, wie die bitrate zwischen dunklen und normalen Szenen verteilt wird. Nennt sich adaptive quantiziser. Setzt man den so, dass er mehr bits für dunkle Szenen nimmt, steigt die Bitrate drastisch an. Der von vielen x265-Anhängern proklamierte Vorteil einer geringen Dateigröße ist dann schnell dahin. In Handbranke kann man das bei x264/x265 einstellen in den "zusätzlichen Parametern" mit aq-mode=3 Hier der Auszug aus der x265-Doku

3. AQ enabled with auto-variance and bias to dark scenes. This is recommended for 8-bit encodes or low-bitrate 10-bit encodes, to prevent color banding/blocking.

https://x265.readthedocs.io/en/2.5/cli.html

Das ganze wird aber bei den Einstellungen ultrafast und superfast blockiert. Mach das mal und vergleiche einmal ein encoding mit aq-mode=3 und einmal ohne. Du wirst von den Dateigrößen überrascht sein. Dann vergleiche es mit einer nach obigen groben Formel berechneten videotoolbox-Kodierung.

Und auch bei viel Bewegung ist x265 eher anders unterwegs und technisch gesehen sogar mit schlechterer Quantisierung. Grund dafür ist, das crf bei Bewegungen den Quantizierer verschlechtert und weniger bits nutzt (da angenommen wird, dass man Artefakte bei schnellen Bewegungen weniger wahr nimmt) und diese eingesparten bits dann bei ruhigen Szenen verwendet, sprich dort auch bessere Quantizierer verwendet. Leider glauben viel User, dass es umgekehrt wäre und mehr bits bei schnellen Szenen genommen würden.

Videottolbox dagegen spricht in den APIs von "encoding quality" was eigentlich bedeutet, das jeder Frame mit dem gleichen Quantizier kodiert wird, sprich auch Szenen mit schnellen Bewegungen erhalten des gleiche, wie in ruhigen Szenen.

x264/x265 machen das um kleinere Dateigrößen zu kriegen. Videotoolbox halt nicht, da werden die Dateien dann eher etwas größer.

Allerdings hat "constant qualitiy" halt Vorteile in Szenen mit viel Bewegung. Wohingegen bei ruhigen Szenen dann constant rate faktor Vorteile bietet, die man aber bei sinnvoll bemessenem Wert für cfr und cq nicht mehr visuell wahr nimmt.

Wichtig is IMO bei Videos die visuelle Qualität, nicht die Dateigröße. Die sieht man beim Video ansehen nicht.

Wer mehr über die verschiedenen rate control Mechanismen crf, cq, cbr, abr wissen will kann hier einiges nach lesen: -> https://slhck.info/video/2017/03/01/rate-control.html

Und speziell zum Unterschied crf vs cq -> https://slhck.info/video/2017/02/24/crf-guide.html

Auch bei diesem Thema ist interessant, dass wenn ich in diesem Thread von "visuell wahrgenommener Qaulität" spreche, viel x264/x265-Anhänger das nicht wahr haben wollen, obwohl gerade x264/x265 mit crf den Weg der visuell wahrgenommenen Qualität bevorzugt gegenüber den technischen Werten.
 
Zuletzt bearbeitet:
WOW. hier geht es nun aber ans eingemachte. Hilfe da muss ich mich ja erst mal mit auseinandersetzten.

Wobei bei dem normalen M1 (in Vollausstattung) man schon merkt, dass VTB viele Geschwindigkeitsvorteile bringt. Weiß jetzt auch nicht, wie es den M1 auf Dauer gefällt, wenn der Stundenlang (VTB evtl. 1 Stunde / X264=265 etc. ohne VTB = 4-6 H in mittlerer Einstellung was die Encodereinstellung angeht.

Glaube der geht da auf Dauer kaputt. Glaube, dass die Pro und Max Prozessoren durch die 8 HP Kerne doch viel flotter sind oder?

Oder nutzt Ihr da dann im Fast oder Ultrafast etc? Bringt das von Ergebnis nicht ggf. schlechtere Resultate wie VTB?
 
Glaube der geht da auf Dauer kaputt. Glaube, dass die Pro und Max Prozessoren durch die 8 HP Kerne doch viel flotter sind oder?
Die CPU wird bei VTB fast nicht genutzt. M1/M1Pro sind da gleich schnell. Dürfte beim Max nicht anders sein da ja gleiche CPU Zahl wie der Pro.
Da geht nichts kaputt.
 
Also alles im allen finde ich VTB schon angenehmer. Schneller und viel leiser. Nur soll halt das Ergebnis nicht so der brüllen sein.
Zumindest wenn ich hier und auch wo anders das alles so richtig verstehe. Habe schon mal in einem englischen Forum gelesen, dass die hoffen, dass Apple mit einen Update die Encoder vom M1 noch verbessern können. Da die so schlecht sein sollen.
 
Ich nutze VTB x265 10 bit mit CQ40 und finde das vollkommen ok. Auch auf dem 83" TV.
 
Also alles im allen finde ich VTB schon angenehmer. Schneller und viel leiser. Nur soll halt das Ergebnis nicht so der brüllen sein.
Zumindest wenn ich hier und auch wo anders das alles so richtig verstehe. Habe schon mal in einem englischen Forum gelesen, dass die hoffen, dass Apple mit einen Update die Encoder vom M1 noch verbessern können. Da die so schlecht sein sollen.

oh mann, ich kann es nicht mehr lesen! Lass es bitte.

Das ist ein dermaßen veraltetes Wissen, das jeder dem anderen nachplappert ohne nur irgendwas mal getestet zu haben. Und diejenigen die testen, verwenden oft die miesesten Parameter, das sie die aktuellen Möglichkeiten gar nicht kennen.

Bitte lies dir doch erst mal diesen Thread (und andere zum Thema in denen ich das schon wiederholt geschrieben habe) durch, bevor du nur irgendwas wiedergibst, was der Bruder, deines Freundes, dessen Onkel es von einem Kollegen gehört hat, der jemanden kennt, der das mal probiert hat.

Wer behauptet, dass videotoolbox mit Hardware-Encoding auf dem M1 _visuell_ schlechter wäre, der hat es einfach nicht probiert oder kennt sich halt nicht sonderlich aus. Klar, wenn du einmal für VT ein cq von 40 setzt und für x265 ein crf von 20, dann ist x265 immer besser, aber nur deswegen,weil du bewusst ein mieses setting verwendest für x265. Bei cq um die 60 ist VT _visuell_ gleichwertig mit x265 crf 20. Nochmals: _visuell_. Die Dateigröße hat nichts mit _visuell_ zu tun.

Edit: ja die Umrechnungformel in Handbrake, die alte Presets mit einem crf Wert von 20 für x265 auf 40 für videotoolbox umrechnet ist schlicht und ergreifend mathematisch falsch. Richtig wäre 60.

x265 crf: 0 = beste 51=schlechteste Qualität
videotoolbox cq: 0 = schlechteste 100 = beste Qualität
 
Zurück
Oben Unten