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

das habe ich eben nicht beschrieben.
Ja doch.

Handbrake rechnet falsch um!
Ja genau das hattest Du ja beschrieben. Das meinte ich damit doch.

Die "Standardeinstellung" von Handbrake ist falsch. Ist das wirklich so schwer zu verstehen?
Das die Einstellung falsch ist, verstehe ich ja!

Was ich meine ist, daß ich bei dem einen Film den Wert auf 56 stehen habe und 4,93 GB (Software 1,21 GB) bekomme, aber mit der Einstellung 28 ein so gut wie nicht unterscheidbares Ergebnis bekomme, aber eine Datei, die nur 1,19 GB groß ist.
Beim anderen Film bekomme ich mit 56 ein super Ergebnis und eine Datei, die genauso groß ist wie bei der Softwareumwandlung.

Wenn ich das irgendwie hinbekomme aufgrund des Films zu unterscheiden, wäre das echt Klasse.
Ich möchte also die 28 für einen Film benutzen, der sonst ein zu großes Ergebnis liefert und die 56 für einen, der sonst ein bildmäßig schlechtes Ergebnis liefern würde.
 
Wenn ich das irgendwie hinbekomme aufgrund des Films zu unterscheiden, wäre das echt Klasse.
Ich möchte also die 28 für einen Film benutzen, der sonst ein zu großes Ergebnis liefert und die 56 für einen, der sonst ein bildmäßig schlechtes Ergebnis liefern würde.

Im vornehinein ist es bei cq unmöglich die Größe vorherzusagen.

Bei videotoobox cq 56 ist immer die gleiche visuelle Qualität. Ebenso ist bei x265 cq 28 immer die gleiche visuelle Qualität. Vollkommen unabhänig vom Material. Das ist Sinn und Zweck von cq. Die Dateigröße wird sich aber je nach Material unterscheiden. Sowohl von Film zu Film, als auch zwischen videotoolbox als auch x265.
 
  • Gefällt mir
Reaktionen: carsten_h, RealRusty und dg2rbf
... würde bei cq auch keinen Sinn ergeben. Die API von Videotoolbox bietet durchaus eine 2-Pass-Kodierung an.
Dass es mit cq nicht geht ist klar, aber als ich es probiert hatte, hat es mit ffmpeg nicht wirklich funktioniert. Hast du es mal probiert?

Da ich mit der konstanten Qualität recht zufrieden bin, habe ich es nicht weiter verfolgt.
 
Dass es mit cq nicht geht ist klar, aber als ich es probiert hatte, hat es mit ffmpeg nicht wirklich funktioniert. Hast du es mal probiert?

nee, habe ich nicht, da es in ffmpeg nicht implementiert ist. Die API selbst gibt es her.

Zudem ist 2-Pass ABR auch nicht besser in der Qualität als cq, da dort eben auch eine Bitrate vorgegeben wird und man die halt nicht im vornehinein so bestimmen kann, dass man eine bestimmte visuelle Qaulität erhält. Wenn man eine Dateigröße vorgeben will, ist 2-pass ABR sicher sinnvoll.

Wie oben geschrieben, hier gibts viele und tiefe Infos dazu -> https://slhck.info/video/2017/03/01/rate-control.html
 
Zuletzt bearbeitet:
Persönlich bin ich schon lange von 2-pass weg, wollte es aber vor einigen Monaten mal probieren wie schnell es mit videotoolboox und ffmpeg geht. Und dass es nicht geht wollte ich hier im Thread nur kurz erwähnen.
 
Im vornehinein ist es bei cq unmöglich die Größe vorherzusagen.
Ja, leider. :)

Ich habe jetzt noch ein wenig herumexperimentiert und bei cq50 hatte ich bei einem Film in einer Szene (durch Zufall gefunden) totale Klötzchenbildung. Bei cq56 war das weg. Ich werde mal die nächsten Sachen mit der Hardware rechnen lassen.

Ist das bei ffmpeg auch so wie ich es oben beschrieben habe, daß der Prozessor (alle Cores) bei videotoolbox trotzdem noch zu 60% belastet ist und die GPU nur bei 25%? Die Performance Cores werden aber nur noch 68°C warm und nicht 80°C.
Oder ist das das spezielle Verhalten von Handbrake, daß Du beschrieben hast?
 
Ist das bei ffmpeg auch so wie ich es oben beschrieben habe, daß der Prozessor (alle Cores) bei videotoolbox trotzdem noch zu 60% belastet ist und die GPU nur bei 25%? Die Performance Cores werden aber nur noch 68°C warm und nicht 80°C.
Oder ist das das spezielle Verhalten von Handbrake, daß Du beschrieben hast?

Das ist das Verhalten von Handbrake. Ich habe ffmpeg gepacht (der patch ist schon seit langer Zeit auf deren devel-mailingliste, aber noch nicht in den sourcen)

ffmpeg mit meinem Patch ist deutlich schneller. Ein encoding von FullHD auf 1920x800 gibt rund 420 fps, bei Handbrake 250, auf dem M1P ca 320 (nach einem anderen user hier, der mein binary hat)

Woran es nun genau liegt, habe ich noch nicht ermitteln könne, habe mich aber auch nicht sehr viel in letzter Zeit damit befasst, da ich bis auf 1 Ausnahme, nur ffmpeg nutze. Es scheint so, dass Handbrake den Hardware-Encoder auf dem M1Pro nicht oder nur gerinfügig nutzt und/oder das Handbrake die Videotoolbox-API nicht korrekt anspricht und so die eigentlich vorhandene Option hinsichtlich der erhöhten Geschwindigkeit überhaupt nicht, oder nur eingeschränkt nutzt. Anders kann ich mir den eklatanten Unterschied zwischen ffmpeg und Handbrake nicht erklären.

Die Ausnahme, wann ich Handbrake nutze, ist übrigens eine frame-rate Umwandlung von NTSC 29.97 auf NTSC Film mit 23,976, da ich alle meine Filme auf 23,976 habe und ggf. konvertiere, da sie so auch aufgenommen wurden. Ungeachtet dessen habe ich Handbrake aber auch noch gepacht um z.Bsp den Fehler der Umrechnung der cq-Werte zu beheben, beim Dolby ProLogic II downmix den LFE-Channel mit rein zu mixen (auch wenn das nicht im Standard vorgesehen und nur optional ist) und default-mäßig die Audiospur als "deutsch" zu markieren.
 
  • Gefällt mir
Reaktionen: carsten_h
ffmpeg mit meinem Patch ist deutlich schneller. Ein encoding von FullHD auf 1920x800 gibt rund 420 fps, bei Handbrake 250, auf dem M1P ca 320 (nach einem anderen user hier, der mein binary hat)
Ok, das ist ja noch einmal etwas.
Gestern habe ich es einmal bei einer Serie in 720p probiert, da war eine Folge in Handbrake in 1:20 fertig. Da ist es eher uninteressant. Ich meine die Softwareversion hat ca. 15 Minuten gerechnet. Allerdings sind auch statt 300MB Ergebnis 200MB Ergebnis herausgekommen.

Dann warte ich einmal bis Deine Patches hereinkommen.

Danke für die ganze Hilfe!
 
Dann warte ich einmal bis Deine Patches hereinkommen.
??? Ich habe gedacht, du magst ffmpeg nicht nutzen, weil du nicht im Terminal arbeiten willst und die Syntax aufwendig sei. Für Handbrake habe ich meine Patches nicht ins Projekt gegeben, da ich keine Lust habe, für jedes Projekt eine andere Form der Meldung zu machen.
 
da ich keine Lust habe, für jedes Projekt eine andere Form der Meldung zu machen.
Ach so. Ich dachte die ffmpeg Patches würden dann irgendwann in den nächsten Jahren in Handbrake einfließen.
Naja, aber 15 min mit Handbrake jetzt statt 2:30 h ist ja auch schon etwas.
 
  • Gefällt mir
Reaktionen: dg2rbf
Zurück
Oben Unten