Videokonvertierung (ffmpeg, handbrake) - MBP 13" M1 deutlich schneller als MBP 14" M1 Pro

Ja, das haben wir verstanden. Deshalb warten wir jetzt fleißig auf eine Problembehebung, einverstanden?
 
biro21 schrieb:
Es geht doch gar nicht um mehr an Leistung, sondern das MBP M1P 14" kommt nicht mal annähernd an die Leistung des MBP M1.
Zum Vergrößern anklicken....
Also geht es doch um die Leistung... :kopfkratz:

Warten ist angesagt... Was anderes bleibt dir nicht und die Hombrew Builds die M1 Support bieten (allerdings auch ohne Pro und Max) willst du ja nicht testen...
 
Zuletzt bearbeitet:
Wollt ihr die Diskussion absichtlich ins lächerliche ziehen? Wir können uns gerne über Fakten unterhalten, aber bitte nicht auf diese Art.

Natürlich geht es um Leistung und zwar darum, dass bestimmte von Apple bereitgestellte Frameworks die u.a. von FinalCut genutzt werden auf dem nagelneuen MBP 14" höchstens 35% der Leistung eines deutlich günstigeren MBP M1 erreichen.

Und da hätte ich gerne die Information wo da der Fehler bzw. was das Problem ist. Ist es ein Problem mit meinem MBP dann werde ich es zurückgeben, denn es ist inakzeptabel. Ist es dagegen ein Problem das durch ein zeitnahes Update behoben wird, dann warte ich gerne, denn ansonsten bin ich recht zufrieden.
 
Bedenkt man die Vielzahl an Software und Softwaremöglichkeiten, so sollte schnell klar werden, dass zuerst die eigene Software an die Hardware angepasst wird und auch da gibt es wie man sieht unterschiedliche Geschwindigkeiten. Bei derart neuer Hardware "ein Fass" auf zu machen, ist andererseits auch wieder bezeichnend für viele heutige threads…
Kein Hersteller hat die personellen Möglichkeiten jede Hard- UND Softwarekonstellation vorab zu testen - das gelingt nicht mal der Masse an "privaten Testern"… (Manche Tücken, Fehler und schlechte Umsetzungen stellen sich erst nach Jahren heraus). Inbesondere Videokonvertierungen /-filter /-Farbkorrekturen / - Renderings sind besonders stark betroffen, zum einen weil hier Hard- und Software besonders eng zusammenarbeiten müssen, zum anderen weil auch jede Hardwarekonfiguration hier eine eigene Anpassung für das Optimum an Leistung braucht. Es funktioniert, aber eben noch nicht optimal. Geduld und Tee trinken. ;)
 
  • Gefällt mir
Reaktionen: vanyedoom
Wir ziehen gar nichts ins Lächerliche. Wir haben verstanden, dass ein Fehler besteht, und wissen auch, dass du damit nicht allein bist. Es gibt aber ja nichts weiter zu diskutieren. Du kannst nur Warten, bis eine neue Version vorliegt, die das Problem ggf. behebt.

Du solltest natürlich den Fehler melden.

Wenn du nicht warten kannst oder willst, gib es halt zurück. Was anderes kannst du eh nicht tun.
 
  • Gefällt mir
Reaktionen: Scum
Wann es mit den Optimierungen los geht musst du bei den Herstellern der Software und/oder Hardware nachfragen.
Ich würde aber nicht davon ausgehen, dass deren Zeitnah mit deiner Definition von Zeitnah übereinstimmt...

Vielleicht ist es auch ein Monterey Fehler. Da gab es noch kein einziges Update...
Vor allem keines, das Fehlerberichte aus der echten Welt berücksichtigt.

Allerdings funktioniert es ja grundsätzlich und es schont - wie es aktuell umgesetzt ist - die Lüfter.
Und ich denke bei den heute eingetrudelten Berichten über gebrickte Geräte und Speicherlecks werden Apples Prioritäten auch nicht auf deinem Problemchen liegen.

Edit: Jemand der Hauptberuflich Videos konvertiert wird nicht auf den "immer direkt das neueste Zug" aufspringen. Andere interessiert das nicht so... Bleiben doch im Grunde nur noch Youtuber mit einem ambitionierteren Fachwissen/Kundenkreis.


Ich würde dir ernsthaft empfehlen die Rückgabe direkt durchzuziehen, wenn du nur ein paar Tage als Deadline hast.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
Mich wundert halt, dass das Problem in wenigen youtube-Videos überhaupt erwähnt wird.

@Lor-Olli Wo genau wird denn ein Fass aufgemacht? Wird irgendein unsachliches Argument verwendet? Stündlich gepostet? Geschimpft?

Der Thread war eigentlich gedacht, dass andere Besitzer der neuen MBPs ihre eigenen Erfahrungen teilen. Und wenn sich einige mit ähnlichen oder auch gänzlich gegenteiligen Erfahrungen melden würden, wäre viel gewonnen und es müsste nicht so viel spekuliert werden.
 
@biro21 ,

- unsachlich? Nicht direkt, aber genau genommen wohl ein recht singuläres Problem das zum einen nur einen verschwindend geringen Anteil an Nutzer betrifft und die meisten wohl auch nicht stört…
- Fass aufmachen? Nicht sprachlich, aber von der Dimension her wird ein Umstand der vermutlich auch der Frühphase weiter anzupassender Software geschuldet ist definitiv aufgebläht!
- Korrekte Darstellung wird kaum medial aufbereitet und "You-Tubisiert"? Liegt unter Umständen daran, dass die meisten User gelernt haben, dass neue Hardware gepaart mit älterer (noch nicht ausreichend angepasster) Software Reibung bietet / bieten kann. Funktioniert die Software trotzdem? Tut sie, wenn auch noch nicht so perfekt wie sich einige das "fordern". (Handbrake z.B. ist kostenlos + open source und wird von Freiwilligen gepflegt, schon mal daran gedacht?)

In der Summe und eingedenk der genannten Fakten würde ich sagen: Hier wird ein Fass aufgemacht…
 
  • Gefällt mir
Reaktionen: dg2rbf, gishmo und walfreiheit
Mit etwas Abstand in der Hoffnung auf sachliche Argumente und nicht weitere ähnliche Beiträge wie oben...

Ein kleiner Vergleich mit Compressor (aktuelle Version - von Apple) getestet auf einem MacBook Pro M1, MacBook Pro M1 Pro (14" - Standardversion) und einem Hackintosh mit einer Intel i9-9900k CPU. 2 verschiedene FullHD-Clips wurden mit HEVC konvertiert, einmal ein 30 Minuten Clip mit der Option HEVC - schneller (videotoolbox) und einmal ein 2 Minuten Clip mit der Option HEVC - besser.

30 Minuten Clip - HEVC schneller

M1 - 3m 40s
M1P - 4m 03s
i9 - 13m 13s

2 Minuten Clip - HEVC besser

M1 - 7m 22s
M1P - 6m 13s
i9 - 7m 07s

Habe den Vergleich bei HEVC schneller mehrfach gemacht und der M1P war in der Regel ca. 10% langsamer als der M1.
 
Nachdem ich die patches und Optimierungen für den M1 bei ffmpeg entwickelt habe, mal ein Gedanke von mir:

ffmpeg ist definitv für den M1 und die Hardware-Encoder-Engine bereit und kann diese auch nutzen. Ob nun jemand, der ein vorgefertigtes Binary vertreibt, dass auch auf M1 cross-compilen kann, weiß ich nicht. Es ist aber ohne Probleme möglich, das selbst zu kompilieren.

Bei meinen damaligen patches wurde eine bedingte Kompilierung von mir eingefügt, die erst ab Big Sur und später greift, da nur dort die Hardware und die API überhaupt vorliegt. Ich habe danach nur nochmal über die devel-Mailingliste mitgekriegt, dass jemand damit ein Problem hatte. Ob dann diese bedingte Kompilierung verändert wurde, kann ich nicht sagen.

Es könnte allerdings gut sein, dass diese bedingte Kompilieren auf Big Sur begrenzt wurde. So war es zumindest damals bei Handbrake. Handbrake hatte das auf Big Sur festgenagelt, so dass ein Kompilieren unter Monterey die hardware-engine gar nicht nutzen würde. Da ffmpeg und Handbrake sehr verwoben sind, könnte es sein, dass auch ffmpeg auf Big Sur festgenagelt wurde (was von mir definitv nicht gewollt war)

Fazit: ich muss mir wohl oder über mal die sourcen von ffmpeg und meinen patch nochmals ansehen.
 
@biro21

Wenn du mit ffmpeg den M1 und den M1P testest, nimmst du da die aktuellen sourcen von ffmpeg und kompilierst diese selbst? Falls ja, dann füge mal bitte den Parameter für 16 b-frames mit ein, also -bf 16 Vielleicht bringt das was. Die aktuellen sourcen haben meinen damaligen patch verändert, so dass meine fest vorgegebenen b-frames von 16 auf 0 gesetzt wurden. ffmpeg muss ein ARM-binary sein, sonst nutzt es nicht die hardware-engine.

Wenn du Handbrake zum Testen verwendest, dann darfst du nicht das Intel-Binary verwenden, sondern eines für Apple Silicon. Notfalls halt selbst kompilieren. Ein Intel-Binary (auch via Rosetta) bietet nicht das gleiche Framework für videotoolbox wie ein natives ARM-Binary. (so war es jedenfalls unter Big Sur).
 
  • Gefällt mir
Reaktionen: vanyedoom
lisanet schrieb:
Da ffmpeg und Handbrake sehr verwoben sind, könnte es sein, dass auch ffmpeg auf Big Sur festgenagelt wurde (was von mir definitv nicht gewollt war)
Zum Vergrößern anklicken....
Das könnte @biro21 ja mal durch Benennung der verwendeten System Versionen etwas feiner aufschlüsseln.
Wobei da ja auch verschiedene Videotoolbox Framework Versionen involviert sind.
 
Von ffmpeg wurde sowohl die unter Monterey auf dem M1P compilierte als auch die alte unter Big Sur auf dem M1 compilierte Version getestet - mit gleichem Ergebnis.

Die letzten Tests waren aber mit der aktuellen Version von Compressor (Teil von FinalCut) und dort war die Konvertierung zu HEVC (mit der Option schneller) auf dem M1P ca. 10% langsamer als auf dem M1.

Hintergrund der Tests ist, dass ich das MBP M1 jetzt am WE weitergebe und dann nicht mehr direkt vergleichen kann, die Ergebnisse mich doch etwas verwundern. Als Ergebnis bin ich froh die Basisversion des 14" geholt zu haben.

@lisanet werde das die nächsten Tage testen.
 
lisanet schrieb:
Es könnte allerdings gut sein, dass diese bedingte Kompilieren auf Big Sur begrenzt wurde.
Zum Vergrößern anklicken....
Wäre es da nicht sinnvoller über die Framework Version zu gehen und das nach configure auszulagern statt hardcoden?
Es gab ja schon häufiger Probleme nach der reinen MacOS Version zu gehen.
Die Änderungen der Nummerierung hat ja schon in der Vergangenheit zu Abfrage Problemen geführt.
 
oneOeight schrieb:
Wäre es da nicht sinnvoller über die Framework Version zu gehen und das nach configure auszulagern statt hardcoden?
Es gab ja schon häufiger Probleme nach der reinen MacOS Version zu gehen.
Die Änderungen der Nummerierung hat ja schon in der Vergangenheit zu Abfrage Problemen geführt.
Zum Vergrößern anklicken....
ja, möglich wäre es. Aber Handbrake hatte halt auf macOS 11 geprüft, wobei ich nicht mher genau weiß und eben erst nachsehen müsste, ob es auch auf größere Versionen hin dort steht, also sowas wie 11+

Diese Makros sind aber Systemmakros und beruhen dann letzendlich auf Frameworkständen.

Ich habe in ffmpeg dagegen auf die Plattform macOS und auf die target CPU arm64 geprüft, was unabhängig von macOS-Versionsnummerierungen ist.
 
biro21 schrieb:
Von ffmpeg wurde sowohl die unter Monterey auf dem M1P compilierte als auch die alte unter Big Sur auf dem M1 compilierte Version getestet - mit gleichem Ergebnis.
Zum Vergrößern anklicken....

noch ein "wenn": Wenn das auch tatsächlich ARM-binaries waren, dann weiß ich auch nichts mehr anderes, als dass entweder das Videotoolbox-Framework einen M1P anderes handhabt oder dass die Hardware-engine auf dem M1P verändert wurde.
 
Vorhin neu compiliert, Aktivitätsanzeige zeigt bei Art "Apple" an, CPU langweilt sich bei 120% (am M1 waren es 350%) und dementsprechend 1/3 der fps. Mit der Option "-bf 16" war es noch langsamer.
 
Kann es sein, dass der M1 dann gar nicht Videotoolbox nutzt sondern nur die CPU?
Videotoolbox läuft ja eher auf der GPU.
 
... hhmm, Handbrake hat viel an den sourcen zu videotoolbox verändert, sie nutzen nicht mehr ffmpeg, sondern sprechen die API direkt an.

ABER: das deplyment-target ist auf 10.13 gesetzt, was dann gegen die APIs von 10.13 linkt. An relevanten Stellen wird aber während runtime auf APIs macOS 11+ geprüft, was dann meines Erachtens dazu führt, dass diese Prüfungen eben ergeben, dass die macOS 11+ APIs nicht vorliegen und daher die hardware-engine nicht benutzt wird, sondern nur die CPU.

Handbrake sourcen geben auch den Hinweis, dass videotoolbox nun 2 Modi kennt: Speed_over_quality und anders rum. Möglich wäre, dass nun als default die quality-setting bevorzugt wird (was typisch für Handbrake wäre). Verbunden mit einem fehlerhaften runtime-check auf die hardware-engine könnte auch das ein Grund für die langsame Geschwindigkeit sein.

Jetzt wäre es interessant, wie es unter ffmpeg aussieht.

Das wird was längeres ....
 
  • Gefällt mir
Reaktionen: biro21
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten