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

G

GoetzPhil

Aktives Mitglied
Thread Starter
Dabei seit
25.01.2019
Beiträge
725
Reaktionspunkte
288
Seit 2 Tagen rechne ich einige meiner Videos mit Handbrake in eine andere Auflösung um. Das erzeugt Last und die 8 CPU Kerne samt der Lüfter liefen mit über 90 Grad heiss.
Aber dafür kauft man sich ja einen Rechenknecht, damit er arbeit verrichtet.

Heute rendere ich gerade wieder ein Video und stelle fest, dass nach etwa 30 Minuten der iMac recht leise ist - tatsächlich die CPU ist nur zu 50% ausgelastet und Handbrake nimmt nur 300% ein. Oh Throttelung denk ich mir, das war die letzten beiden Tage nicht der Fall.
Also beende ich den Job und warte ein paar Minuten - wobei kühl ist der iMac ja bereits.

Dann starte ich Handbrake erneut und die CPU geht auf 800% und 93Grad - und nach wenigen Sekunden laufen auch die Lüfter hoch.
Doch die letzten 2 Tage lief der Handbrake Job immer unter Volllast durch - nach 30 Minuten war die Encodierung beendet.
Jetzt stelle ich fest dass nach gut 5 Minuten die CPU bereits drosselt - und de Encodierung mit nur noch 300% CPU erfolgt!
Also versuche ich es nocheinmal, mit einem anderen Video.
Da wird aber nichtal mehr die CPU heiss, denn von vornherein kommt Handbrakenicht über 300% CPU.

Hat Apple da einen Mechanismus eingebaut, der erkennt wenn eine APP längere Zeit die CPUs belastet?
Und dass dann knallhart die Performance für diese APP begrenzt wird?
Wie gesagt, die letzten 2 Tagetrat es nicht auf, deswegen bin ich heute umso erstaunter dass selbst bei kalter Performance CPU (42 Grad) Handbrakeweiter nur 300% CPU bekommt und eben NICHT wieder hochschaltet um PERFORMANT zu sein.

Sind die M1 Chips etwa doch nicht so performant wie Apple das gern erzählt und müssen geschützt werden, damit sie nicht durchbrennen?
 
Zuletzt bearbeitet:
Sind die M1 Chips etwa doch nicht so performant wie Apple das gern erzählt und müssen geschützt werden, damit sie nicht durchbrennen?

Handbake ist wohl kaum schon für Apple Silicon optimiert.
Zumindest steht davon kein Wort in der Online-Dokumentation.
 
  • Gefällt mir
Reaktionen: Z4Devil, gishmo und dg2rbf
Hi,
Handbrake ist GNU Freeware, da kann es schon ne geraume Zeit dauern bis diese Software an die neuen Apple Prozessoren angepasst wird.
Franz
 
  • Gefällt mir
Reaktionen: Z4Devil und gishmo
Hi,
Dann kann es nur ein Bug sein, der in Handbrake steckt.
 
  • Gefällt mir
Reaktionen: Stargate
Handbake ist wohl kaum schon für Apple Silicon optimiert.

Handbrake ist natürlich auf Apple Silicon optimiert und nutzt auch via Videotoolbox hochoptimierte SIMD-Funktionen und die encoder-engines des M1. Handbrake basiert auch auf den librariers von ffmpeg. Und dafür habe ich vor einiger Zeit die Optimierungen die Handbrake bereits hatte nach ffmpeg portiert, so dass diese nun faktisch identisch optimierte Routinen verwednen. Diese Portierungen sind auch in ffmpeg eingepflegt.

Wenn die Umkodierung soviel Last erzeugt, dann wird definitiv nicht Videotoolbox mit hardware-optimierten Codecs verwendet.
 
  • Gefällt mir
Reaktionen: dg2rbf
Hi,
Handbrake ist GNU Freeware, da kann es schon ne geraume Zeit dauern bis diese Software an die neuen Apple Prozessoren angepasst wird.
Franz

Sorry, das ist leider volkommen falsch. Handbrake ist bereits sehr frühzeitg nativ für den M1 erschienen und nutzt traditionell sehr gut die Hardwaremöglichkeiten aus. Ebenso ffmpeg.
 
Hi,
Dann kann es nur ein Bug sein, der in Handbrake steckt.

Nein, hohe Last ist eher ein Zeichen dafür, dass eben nicht die Hardware-Encoder des M1 verwendet werden. Nimmt man diese, dann langweilt sich die CPU.
 
  • Gefällt mir
Reaktionen: mausfang, JARVIS1187 und dg2rbf
Nein, hohe Last ist eher ein Zeichen dafür, dass eben nicht die Hardware-Encoder des M1 verwendet werden. Nimmt man diese, dann langweilt sich die CPU.
und wie kann der user das beinflussen?

hab selbst ein paar videos in hd qualität vom iphone 11 meiner frau durch handbrake laufen lassen. keine 2 minuten und die lüfter vom mbp 13 m1 liefen auf hochtouren. da wird das ding wohl dann auch den falschen encoder genommen haben
 
Dann könnte ich mir gut vorstellen, dass es an der Art des Video-Quellmaterials liegt.

Möglicherweise sind einige Videos in einem "M1 HW-Beschleuniger kompatiblen" Format codiert und andere nicht, so dass die CPU die Umwandlung durchführen muss.

@GoetzPhil:
Hast Du mal geschaut in welchem Format (MPEG2, H264, H265 etc.) Deine Videos codiert sind?
 
nutzt auch via Videotoolbox hochoptimierte SIMD-Funktionen und die encoder-engines des M1.
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/
 
  • Gefällt mir
Reaktionen: Roman78 und mausfang
Es scheint eher ein Fehler bei Apple zu sein, Handbrake arbeitet ok, nur wen man die Kodierung anhält ud später weiterlaufen lässt tritt der Fehler auf.
 
  • Gefällt mir
Reaktionen: dg2rbf
Beim M1 scheint der Hardware-Encoder sogar richtig schlecht zu sein. Zwar super schnell aber bis hin zu grauenhaft hinsichtlich Qualität/Dateigröße.

Hast du es schon mal selbst probiert und verglichen, oder zitierst du nur von irgendwelchen uralten Aussagen aus dem Netz, die keine Ahnung davon haben, wie mittlerweile ffmpeg mit videotoolbox auf dem M1 umgeht?

Die Zeiten, wo ein Hardware-encoder nur konstante Bitrate und Intra-Frames beherrschte sind lange vorbei. Auch constant quality ist kein Thema mehr (durch meinen Patch) oder B-pyramid.

Klar, wenn du natürlich auf software setzt, die ultra langsam versicht ide Qulität zu optimieren, dann kannst du mit x264/x265 messtechnisch bessere Werte erhalten. Aber visuell siehtst du keinen Unterschied zu videotoolbox und das bei durchaus vergleichbaren kbps. Von der Zeit mal ganz zu schweigen. In den aktuellsten Sourcen erwähnt zudem Handbrake, dass videotoolbox nun 2 Modi kennt, die die Balance zwischen Zeit und Qualität ändern. Hierin vermute ich einen möglichen Grund für die hier diskutierte veränderte Geschwindigkeit.

Aber, wie bei allen derartigen Diskussionen, nimm was du willst und vergleiche selbst mal. Wenn für dich Dateigröße heuzutage noch diese hohe Bedeutung hat, bitteschön. Du hast ja Gott sei Dank die Wahl.
 
- Ich habe zwar einen M1, benutze aber nicht die VideoToolbox.
- Ich versuche das Maximum an Qualität und Dateigröße rauszubekommen. Da ist ist die Videotoolbox die falsche Wahl.
- Bei den paar Videos, die ich im Jahr encodiere, ist es mir egal ob das auf der CPU länger dauert.
- Die HardwareEncoder sind alle mehr oder weniger schlecht. Die einzige positive Aufnahme scheint NVENC von NVIDIA zu sein. NVENC soll wohl fast an gutes Software-Encoding rankommt; jedenfalls ist das der HardwareEncoder, über den ich schon gute Dinge gelesen habe.
- VideoToolbox wird in vielen Programmen (und auch Benchmarks) i.d.R. ohne ffmpeg genutzt.
- Platzverbrauch: Im Beispiel oben waren 7GB Unterschied (subjektive visuelle Wahrnehmung des Users); kommt natürlich auf die Szenen an; mag sein, dass das ein Extrembeispiel ist.
- Dass VideoToolbox mittelmäßige bis richtige schlechte Qualität (in Verbindung mit Dateigröße) liefert, liest man an verschiedenen Stellen (u.a. im Handbrake-Forum, macrumors-Forum an verschiedenen Stellen, AppleForum selber etc.). Das allgemeine Fazit ist bisher, dass man die Finger davon lässt, wenn einem auch Qualität/Dateigröße wichtig ist.
Die ganzen Jubler, schauen alle nur auf die Geschwindigkeit und ignorieren das Thema Qualität/Dateigröße komplett (sind sich dem wahrscheinlich auch gar nicht bewusst und wenn doch, ist es denen egal => "nur" für den Kunden war mal die Antwort, die ich erhalten hatte). [Noch besser ist, wenn Rechner A) auf der VT getestet wird und Rechner B auf der CPU und dann als Aussage kommt, dass A doch soviel besser sei... und nicht merken, dass die gar nicht die CPU Leistung vergleichen... sondern HardwareEncoder vs. CPU.]
- Wenn VT in Verbindung mit ffmpeg mittlerweile vergleichbare Qualität liefert wie nur auf der CPU (habe Zweifel), dann schaue ich mir das gerne bei Gelegenheit mal an, sofern es brauchbare Infos/Vergleiche gibt bzw. wenn sich das bestätigen sollte, ändere ich meine Sicht durchaus (habe da aber nach wie vor Zweifel, dass dem so ist).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Z4Devil
Die ganzen Jubler, schauen alle nur auf die Geschwindigkeit und ignorieren das Thema Qualität/Dateigröße komplett (sind sich dem wahrscheinlich auch gar nicht bewusst und wenn doch, ist es denen egal => "nur" für den Kunden war mal die Antwort, die ich erhalten hatte).

okay, du selbst hast es also noch nie probiert, bezeichnest aber andere User:innen, die VT nutzen als "Jubler", die sich entweder der Qualität nicht bewusst seien oder denen das egal wäre.

Eine sehr herablassende Einstellung von dir. Naja, ich jedenfalls juble gerne und bin mir nach deinen bisherigen Postings zu urteilen rundum sicher, dass ich drastisch mehr Erfahrung in Videoencoding habe als du und durchaus die Fähigkeit, Qualität von encodings zu beurteilen und zudem den Unterschied kenne, zwischen Messwerten und visuell wahrnehmbarer Qualität. Nicht vom Hörensagen, sondern selbst erlebt.

Aber letztendlich ist das eine vergleichbare Diskussion wie mit den User:innen, die vorgeben einen Unterschied hören zu können zwischen AAC 256 und Losslesss 24/192. Interessant ist im Vergleich zu Audio, dass bei Audioencoding die Dateigröße keine Rolle spielt bei den Befürwortern von lossless 24/192, wohingegen bei Videoencoding auf einmal die Dateigröße ein bedeutendes Argument wird.

Nun denn, du hast ja deine Lösung gefunden und bist damit glücklich.
 
  • Gefällt mir
Reaktionen: Apfelfuzzi und pk2061
was soll der user jetzt einstellen damit es für den m1 optimal läuft? man könnt ja meinen das handbrake etwas grundintelligenz hätte und selbst das beste auswählt für den jeweiligen preset und prozessor.

wenn ich present hq 1080p30 surround auswähle wird videoencoder h.264 (x264) genommen. soll man da den h.264 (videotoolbox) nehmen oder gar den h.265 (videotoolbox)

achja weil hier immer alle von kompilieren und so schreiben. bin etwas verwirrt.

reicht nicht einfach https://handbrake.fr/rotation.php?file=HandBrake-1.4.2.dmg oder muss ich dann tatsächlich noch irgendwelche sachen wie ffmpeg oder so installieren oder kompilieren?
 
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.
Hast du das wirklich selber getestet?

Kann nur sagen, dass ich nach interessanter Diskussion mit @lisanet da etwas rumprobiert hatte und sehr angenehm von den Ergebnissen überrascht war.
Die ganzen Jubler, schauen alle nur auf die Geschwindigkeit und ignorieren das Thema Qualität/Dateigröße komplett (sind sich dem wahrscheinlich auch gar nicht bewusst und wenn doch, ist es denen egal => "nur" für den Kunden war mal die Antwort, die ich erhalten hatte). [Noch besser ist, wenn Rechner A) auf der VT getestet wird und Rechner B auf der CPU und dann als Aussage kommt, dass A doch soviel besser sei... und nicht merken, dass die gar nicht die CPU Leistung vergleichen... sondern HardwareEncoder vs. CPU.]
Mich stören an solchen Beiträgen Worte wie Jubler, weil sie im vorhinein jeden mit einer von deiner abweichenden Meinung abwerten.
- Wenn VT in Verbindung mit ffmpeg mittlerweile vergleichbare Qualität liefert wie nur auf der CPU (habe Zweifel), dann schaue ich mir das gerne bei Gelegenheit mal an, sofern es brauchbare Infos/Vergleiche gibt bzw. wenn sich das bestätigen sollte, ändere ich meine Sicht durchaus (habe da aber nach wie vor Zweifel, dass dem so ist).
Genau diesen Vergleich habe ich via Pixelpeeping sogar gemacht und war ziemlich überrascht wie gut die Qualität von videotoolbox sein kann wenn man die entsprechenden Einstellungen vornimmt. Nutze persönlich x265 und variiere bei der Qualität zwischen 65 und 55. Bei wenig verrauschtem Bild sehe ich zwischen CRF18 (bei normalem x264 ohne videotoolbox) und q 65 (x265 videotoolbox) nahezu keinen Unterschied wenn ich einzelne Standbilder nebeneinander anschaue. Sind die Bilder sehr verrauscht, wird eine Qualität von 60 oder gar 55 gewählt. Wir sehen auf einem 65" LG OLED.
 
  • Gefällt mir
Reaktionen: dg2rbf
okay, du selbst hast es also noch nie probiert, bezeichnest aber andere User:innen, die VT nutzen als "Jubler", die sich entweder der Qualität nicht bewusst seien oder denen das egal wäre.
Ja natürlich sind das Jubler (die Jubler nutzten i.d.R. wissentlich oder unwissentlich die VT aber nicht in Handbrake sondern FCPX & Co). Gefühlt 99 Prozent derer, die diese Benchmarks so hervorheben und damit "angeben", haben sich noch nie annähernd mit dem Thema beschäftigt. Die wissen meist noch nichtmal, dass es unterschiede zwischen den verschiedenen Encodern für einen Codec gibt. Manche wissen noch nicht mal, dass es HardwareEncoder gibt. Das einzige Kriterium ist für diese "Jubel" dann die Encodinggeschwindigkeit. Es gibt sogar Spezialisten auf YouTube, die bei Rechner a) die VT anhaben und auf b) nicht (bzw. keine HardwareEncoder) und dann nur mit dem Kriterium Encodinggeschwindigkeit vergleichen und das Ergebnis dann bejubeln bzw. als Indiz für CPU-Performance nehmen...

Naja, ich jedenfalls juble gerne und bin mir nach deinen bisherigen Postings zu urteilen rundum sicher, dass ich drastisch mehr Erfahrung in Videoencoding habe als du und durchaus die Fähigkeit, Qualität von encodings zu beurteilen und zudem den Unterschied kenne, zwischen Messwerten und visuell wahrnehmbarer Qualität. Nicht vom Hörensagen, sondern selbst erlebt.
Lass stecken.
VT (aus FinalCut) habe ich natürlich schon verwendet, für Draft. Das Ergebnis war IMHO schlechter als das finale Video (ProRes in Handbrake). Richtiger Vergleich, geschweige denn Pixelpeeping war nicht der Hintergrund damals, sondern einfach nur schnelles Draft. Wenn mir mal langweilig sein sollte, hole ich das vielleicht mal nach.
Und so ziemlich jeder (du scheinst die Ausnahme zu sein), den man im Netz dazu findet und der wirklich vergleicht, sagt dass die Qualität + Dateigröße mit hochwertigem Encoder auf der CPU besser ist. Sichtbare Qualitätsunterschiede, je nach Art des Materials + Unterschiede in der Dateigröße.

In Handbrake habe ich die VT wirklich noch nicht genutzt. Mag sein, dass da mehr möglich ist und der Unterschied kleiner wird.
Wie ich schon schrieb:
Da ich nicht täglich Videos encodiere, gehe ich auf Nummer sicher und mach das auf der bewährten CPU.

Aber letztendlich ist das eine vergleichbare Diskussion wie mit den User:innen, die vorgeben einen Unterschied hören zu können zwischen AAC 256 und Losslesss 24/192. Interessant ist im Vergleich zu Audio, dass bei Audioencoding die Dateigröße keine Rolle spielt bei den Befürwortern von lossless 24/192, wohingegen bei Videoencoding auf einmal die Dateigröße ein bedeutendes Argument wird.
Das lässt sich nicht vergleichen. Vor allem habe ich nirgends gesagt, dass mir die Dateigröße bei Audio egal ist (und bei Video sind das zudem andere Dimensionen).
Und meine eigene Musik habe ich in der Tat in Flac archiviert. In erster Linie, um flexibel zu sein, wenn ich mal ein anderes Dateiformat brauche, um nicht reencodieren zu müssen.
Und nebenbei bemerkt: Zumindest früher in den 2000ern, als ich meine Flacs erstellt habe, ist z.B. MP3 noch nicht mit dem "scalefactor band 21"-Problem klar gekommen. Da gab es bestimmte Stücke oder Killa-Samples, die den Codec an die Grenzen getrieben haben. Habe die Entwicklung nicht mehr weiter verfolgt. Kann sein, dass die "neueren" Lame-Versionen damit klar kommen. OK, mp3 ist kein AAC.

Genau diesen Vergleich habe ich via Pixelpeeping sogar gemacht und war ziemlich überrascht wie gut die Qualität von videotoolbox sein kann wenn man die entsprechenden Einstellungen vornimmt. Nutze persönlich x265 und variiere bei der Qualität zwischen 65 und 55. Bei wenig verrauschtem Bild sehe ich zwischen CRF18 (bei normalem x264 ohne videotoolbox) und q 65 (x265 videotoolbox) nahezu keinen Unterschied wenn ich einzelne Standbilder nebeneinander anschaue. Sind die Bilder sehr verrauscht, wird eine Qualität von 60 oder gar 55 gewählt. Wir sehen auf einem 65" LG OLED.
Danke für die Info.
 
Zuletzt bearbeitet:
VT (aus FinalCut) habe ich natürlich schon verwendet, für Draft. Das Ergebnis war IMHO schlechter als das finale Video (ProRes in Handbrake). Richtiger Vergleich, geschweige denn Pixelpeeping war nicht der Hintergrund damals, sondern einfach nur schnelles Draft. Wenn mir mal langweilig sein sollte, hole ich das vielleicht mal nach.
Und so ziemlich jeder (du scheinst die Ausnahme zu sein), den man im Netz dazu findet und der wirklich vergleicht, sagt dass die Qualität + Dateigröße mit hochwertigem Encoder auf der CPU besser ist. Sichtbare Qualitätsunterschiede, je nach Art des Materials + Unterschiede in der Dateigröße.

Genau darum geht es aber, dass auch du nur das wiederholst, was irgendwelche anderen User im Netz von sich geben. Und das kombinierst du dann mit der Herabwürdigung anderer als "Jubler". Du hinterfragst nicht, ob deine Quellen überhaupt noch aktuell sind und sich daher vielleicht einfach auf dem Holzweg befinden.

Und ja, es kann gut sein, dass ich eine der wenigen bin, die VT anders beurteilen. Warum? Weil ich mir die Mühe gemacht habe, ffmpeg für VT (genauer gesagt HEVC) um constant quality und Verwendung von B-pyramids erweitert habe (der patch ist auch mittlerweile enthalten) und daher weiß, wie ich ffmpeg aufrufen muss. Und das macht den Unterschied aus: Wissen über die Anwendung eines Tools. Nicht nur stupides abtippen irgenwelcher uralten Anleitungen aus dem Netz und nachplappern von ebenso veralteten Resultaten.

Wenn du auf vielen Seiten, die sich mit ffmpeg beschäftigen nachsiehst, findest du eben nur Ausführungen genau ohne diese Möglichkeit der constant quality. Handbrake nutzt das übrigens auch noch nicht so lange und auch nur dann, wenn ein natives ARM-Binary genutzt wird und nicht die identische Version via Rosetta. Und ja, es ist ein deutlicher Unterschied zwischen VT auf einem M1 und einem Intelrechner.

Zudem habe ich erst vor wenigen Tagen ffmpeg für den M1 nochmals gepacht - und werde dies natürlich auch upstream einbringen - dass bei constant quality die Kodiergeschwindigkeit nochmals gesteigert wurde um ca. 100%. Auch da wird es dann halt wieder so sein, dass nur diejenigen davon wissen werden, die sich mal die Mühe machen, die Hilfeanzeige der encoder oder die Doku zu lesen. Das kann man jetzt gut oder schlecht finden, dass so etwas nicht per default eingeschaltet ist, aber so ist nun mal die Philosophie von ffmpeg. Bei FCP mag dies anders sein.

Und darum wäre es gut, wenn du dich mal wirklich damit befasst und nicht einfach blind drauf los andere User:innen, die in diesem Punkt mehr Wissen als du haben, als "Jubler" herabwürdigst.
 
  • Gefällt mir
Reaktionen: bruderlos, biro21 und dg2rbf
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.
 
Zurück
Oben Unten