m1 - h265 hardware encoder?

[dany2k]

Hallo alle zusammen,

kurze Frage:

Welche Möglichkeiten/Programme gibt es, Videos mit h265 mit der hardware zu encoden?
bezüglich videotoolbox etc. leste ich bereits einige probleme .

Vielleicht hat irgendwer da mehr Erfahrungen bzw. Vorschläge die er hier mit mir teilen könnte.
Gibt es eine Möglichkeit mit ffmpeg dass dies hardwareseitig gemacht wird ??

LG

 

[Tzunami]

Hallo alle zusammen,

kurze Frage:

Welche Möglichkeiten/Programme gibt es, Videos mit h265 mit der hardware zu encoden?
bezüglich videotoolbox etc. leste ich bereits einige probleme .

Vielleicht hat irgendwer da mehr Erfahrungen bzw. Vorschläge die er hier mit mir teilen könnte.
Gibt es eine Möglichkeit mit ffmpeg dass dies hardwareseitig gemacht wird ??

LG

leste?

Handbrake unterstützt z.B. Videotoolbox. Ich bevorzuge allerdings CPU-encoding, da dort mehr Optimierungspotential beim Codec besteht.

Mir ist es schon passiert, dass bei VideoToolbox leere Dateien herauskommen.

 

[iPhill]

Welche Möglichkeiten/Programme gibt es, Videos mit h265 mit der hardware zu encoden?

iMovie, Final Cut, Handbrake ... können den sicher nutzen.
Also mit Handbrake kannst H.265 sicherlich manuell auswählen.

Ich würde allerdings nur dann auf VideoToolbox (H.264/H.265 Hardware) setzen, wenn es schnell gehen muss oder man einfach kurz einen Film an einem Gerät ansehen will, das den aktuell vorliegenden Original-Codec nicht nutzen kann (z.B. ältere TVs oder auch ältere Streaming Lösungen).
Sonst würde ich immer auf Software Encoding setzen: Bessere Qualität bei kleinerer Dateigrösse, da wie von @Tzunami schon gesagt, höheres Optimierungspotenzial gegeben ist.
Für langfristig-hochwertige Files setze ich z.B. auf H.264/265 bei Constant Quality mit RF 17-21 (je tiefer die Quell-Auflösung, desto tiefer mein gewählter RF Wert); Encoder Preset nutze ich dann jeweils 'veryfast' in Handbrake.

 

[lisanet]

Nutze videotoolbox entweder wie schon mal geschrieben mit HandBrake oder im Terminal mit ffmpeg.

Das was andere behaupten, dass eine CPU-Koiderung "besser" wäre ist nicht korrekt.

Sowohl CPU als auch Hardware-Encoder können "constant quality" nutzen, was bedeutet, das die visuelle Qualität ausschlaggebend ist. Bei vergleichbaren settings zu constant quality zwischen CPU und Hardware-Encoder wirst du visuell keinen Unterschied erkennen können.

Was die Datei-Größe betrifft: Bei Audio-Kodierung ist hier die Meinung der User, dass die Qualität vorgeht und die Dateigröße nicht relevant ist. Die gleichen User meinen nun, dass augerechnet bei Video, die Dateigröße irgendein Qualitätsmerkmal sei. Das ist es aber nicht. Bei Video kommt es halt auf die visuelle Qualität an.

Bei ffmpeg z.Bsp ist für x265 ein crf von 20 bei Full-HD eine sehr gute visuelle Quzalität. Das enspricht bei hevc_videotoolbox einer cq von 60 (Die Skalen sind gegenläufig. x265 0 - 51 mit 0 = beste Qauli und videotoolbox von 0 - 100 mit 100 = beste Qauli)

Ich habe vor einiger Zeit genau das als PAtch zu ffmpeg beigesteuert un d traue mir daher eine sehr fundierte Aussage zu.

Zudem ist Hardware-Encoding drastisch schneller bei vergleichbarer visuelle Qualität. Geschwindigkeitsvergleich: BluRay encoding zu 1920x800 mit DD-Ton mit ffmpeg auf einem Mac Studio M1 Max bis zu 520 fps. mit x265 vielleicht 10% davon.

 

[iPhill]

Sowohl CPU als auch Hardware-Encoder können "constant quality" nutzen

Also hier geht das mit Handbarke 1.7.1 und VideoToolbox nicht (mehr(?)). Da klappt nur avg bitrate.

 

[AgentMax]

Wird hier weiterhin angeboten.

 

[iPhill]

Wird hier weiterhin angeboten.

Seltsam, hier, CQ ausgegraut (sowohl für H.264 als auch H.265):

... akutelle Stable von HB:

 

[AgentMax]

Wähl mal Konstante Bildfrequenz.

 

[iPhill]

Wähl mal Konstante Bildfrequenz.

Keine Änderung. Aber mai, dann ist das halt hier (warum auch immer(!?)) so!
Ich brauch den HW Encoder sowieso so gut wie nie.

... keine Ahnung ob sich das zwischenzeitlich geändert hat: Aber ich hatte vor noch gut 'nem Jahr mal immer wieder HW Encoding über 'ne Nvidia RTX GraKa laufen lassen, das war ultra schnell und da gab's in Handbrake auch die CQ zur Auswahl. ABER: Die Files waren meistens 50%, wenn nicht beinahe doppelt so gross wie wenn der SW Encoder von x264/265 genutzt wurde.
Vielleicht wäre das jetzt am M1/M2/M3 anders - keine Ahnung, aber irgendwie bin ich in der Hinsicht eher etwas skeptisch. Zu Recht oder eher zu Unrecht?
Gelle! Ich lass mich (nicht zu letzte des Zeitgewinns wegen!) sehr gerne eines [Neueren] Besseren belehren!

 

[Tzunami]

Nutze videotoolbox entweder wie schon mal geschrieben mit HandBrake oder im Terminal mit ffmpeg.

Das was andere behaupten, dass eine CPU-Koiderung "besser" wäre ist nicht korrekt.

Sowohl CPU als auch Hardware-Encoder können "constant quality" nutzen, was bedeutet, das die visuelle Qualität ausschlaggebend ist. Bei vergleichbaren settings zu constant quality zwischen CPU und Hardware-Encoder wirst du visuell keinen Unterschied erkennen können.

Ich rede nicht von "constant quality", sondern von Funktionen wie:

Referenz-Frames
B-Frames
Motion Estimation Methode
Subpixle ME
ME Range
Adaptive Quantisierung
usw.

 

[lisanet]

Ich rede nicht von "constant quality", sondern von Funktionen wie:

Referenz-Frames
B-Frames
Motion Estimation Methode
Subpixle ME
ME Range
Adaptive Quantisierung
usw.

All diese Dinge haben keinen Einfluss auf die visuelle Qualität, sondern auf die Dateigröße.

Zudem sind diese Dinge ebenso ion Hardware abbildbar. Für videotoolbox kann ich es dir z.Bsp definitv bestätigen, dass b-frames als auch pyramidale b-frames sogar konfigurerbar sind. Ebenso wie die GOP-Size. Die anderen Dinge müsste ich mal an den Headern des videotoolbox frameworks vorbei führen. Naja, und wenn du mit "Referenz-Frames" I-Frames meinst, dann sei dir versichert, dass alleine wegen des Vorhandenseins einer variable GOP-Größe und b-frames, sowohl I-Frames als auch P-Frames vorhanden sein müssen. Sonst ginge das ja gar nicht.

Sorry, aber irgendweie klingt das für mich so, als ob du gerade nur irgendwelche Begrifflichkeiten aufzählst, ohne genau zu kennen, was diese bewirken.

Es geht um visuelle Qualität. Und bei vergleichbaren Einstellungen zu constant quality bei x264/x265 und videotoolbox wirst du eben visuell keine Unterschiede feststellen können. Egal ob welche Methode der motion estimation du nutzen wirst. Das ist ja eben genau Sinn und Zweck dieses Parameters wie ihn Hanbrake mit "constant quality" bezeichnet.

Und rein vorbeugend: ich weiß, dass x264/x265 in Handbrake eigentlich "constant rate factor" verwendet und da in der GUI halt leider anders nennt. Ich nenne das daher auch "constant quality", um etwas weniger Verwirrung bei nicht so tief in der Materie sitzenden Usern zu stiften.

 

[lisanet]

Seltsam, hier, CQ ausgegraut (sowohl für H.264 als auch H.265):

Anhang anzeigen 415287

... akutelle Stable von HB:

Anhang anzeigen 415289

Du nutzt vermutlich einen Intel-Rechner.

Die Hardware-Encoder der Intel-Macs bieten nicht alle Funktionen an. "constant quality" und etliches andere wurde erst für die Apple Silicon Rechner in videotoolbox implementiert.

Das bedeutet u.a., dass es notwendig ist auf M-Macs auch native Apple Silicon Versionen von ffmpeg/Handbrake zu verwenden, damit die Funktionen erhältlich sind. Eine Intel-only-Version läuft zwar dank Rosetta2, aber eben nicht mit diesen neuen, erweiterten Funktionen.

 

[iPhill]

Du nutzt vermutlich einen Intel-Rechner.

True that. - Ach so, ichd dachte die können das über Intel QuickSync Video auch schon, aber dann wohl, wie du schreibst, nur sehr beschränkt.
Interessant.

Wie verhält es sich mit M Chips hinsichtlich der Filesize bei CQ? Auch deutlich grösser als bei SW Encode oder wurde da ordentlich optimiert?
Muss das mal mit dem M1 Max im MBP16" ausprobieren; bei sonst gleichen Einstellungen einen Vergleich von H.264/265 und H.265/265 (Videotoolbox) bei CQ 20.

 

[oneOeight]

Der Trend geht doch eh zu AV1.
Ach, da war ja das Problem das Apple das lange nicht wollte aber zumindest jetzt einen Hardware Decoder ab M3 verbaut.

 

[Tzunami]

All diese Dinge haben keinen Einfluss auf die visuelle Qualität, sondern auf die Dateigröße.

Zudem sind diese Dinge ebenso ion Hardware abbildbar. Für videotoolbox kann ich es dir z.Bsp definitv bestätigen, dass b-frames als auch pyramidale b-frames sogar konfigurerbar sind. Ebenso wie die GOP-Size. Die anderen Dinge müsste ich mal an den Headern des videotoolbox frameworks vorbei führen. Naja, und wenn du mit "Referenz-Frames" I-Frames meinst, dann sei dir versichert, dass alleine wegen des Vorhandenseins einer variable GOP-Größe und b-frames, sowohl I-Frames als auch P-Frames vorhanden sein müssen. Sonst ginge das ja gar nicht.

Sorry, aber irgendweie klingt das für mich so, als ob du gerade nur irgendwelche Begrifflichkeiten aufzählst, ohne genau zu kennen, was diese bewirken.

Es geht um visuelle Qualität. Und bei vergleichbaren Einstellungen zu constant quality bei x264/x265 und videotoolbox wirst du eben visuell keine Unterschiede feststellen können. Egal ob welche Methode der motion estimation du nutzen wirst. Das ist ja eben genau Sinn und Zweck dieses Parameters wie ihn Hanbrake mit "constant quality" bezeichnet.

Und rein vorbeugend: ich weiß, dass x264/x265 in Handbrake eigentlich "constant rate factor" verwendet und da in der GUI halt leider anders nennt. Ich nenne das daher auch "constant quality", um etwas weniger Verwirrung bei nicht so tief in der Materie sitzenden Usern zu stiften.

Klar, sind das nur Funktionen die Größe beeinflussen, aber einige Leute haben es halt auch gerne klein bei guter Qualität. Man könnte sonst ja auch mit RAW arbeiten, wenn die Größe unwichtig wäre.

Also ich habe es gestern nochmal versucht und beim Ergebnis habe in immer 1 b-Frame und keine der Modifikationen werden bei der Komprimierung übernommen.

Hier mal die Einstellungen bei CPU

Selbe Einstellungen bei GPU. B-frames und andere Einstellungen werden nicht übernommen.

 

[Tzunami]

True that. - Ach so, ichd dachte die können das über Intel QuickSync Video auch schon, aber dann wohl, wie du schreibst, nur sehr beschränkt.
Interessant.

Wie verhält es sich mit M Chips hinsichtlich der Filesize bei CQ? Auch deutlich grösser als bei SW Encode oder wurde da ordentlich optimiert?
Muss das mal mit dem M1 Max im MBP16" ausprobieren; bei sonst gleichen Einstellungen einen Vergleich von H.264/265 und H.265/265 (Videotoolbox) bei CQ 20.

Da die Skalen unterschiedlich ist (CPU RF 20 ≠ GPU CQ 20) brauchst du erst mal die Umrechnung. Ich glaube lisanet hatte die hier mal irgendwo gepostet. Da weiß ich allerdings auch nicht, ob sie das durch Versuche ermittelt hat, oder ob es dazu eine Erklärung der Programmierer gab.

Zur Größe:
ich komme hier auf 554 MB bei CPU (Encodereinstellung: mittel RF=20) und 614 MB bei GPU (Encodereinstellung: quality CQ=60)

Ich lasse gerade noch CPU Encodereinstellung "slow" durchlaufen, dauert noch 2 min.

EDIT: Encodereinstellung: slow 547 MB. Quelle war übrigens eine SD Video, bei HD wäre der Unterschied wahrscheinlich erheblich größer. Ich teste mal

 

[Tzunami]

Du nutzt vermutlich einen Intel-Rechner.

Die Hardware-Encoder der Intel-Macs bieten nicht alle Funktionen an. "constant quality" und etliches andere wurde erst für die Apple Silicon Rechner in videotoolbox implementiert.

Das bedeutet u.a., dass es notwendig ist auf M-Macs auch native Apple Silicon Versionen von ffmpeg/Handbrake zu verwenden, damit die Funktionen erhältlich sind. Eine Intel-only-Version läuft zwar dank Rosetta2, aber eben nicht mit diesen neuen, erweiterten Funktionen.

Huhu lisanet,

ich habe jetzt mal dein Umrechnungsfaktor (videotoolbox = 100 - 2*x265) verwendet. Diese müsste ja dann auch für h.264 gelten. Allerdings ist das Bild bedeutend schlechter und es gibt Abrisse bei Verläufen. Woher hast du diese Umrechnung?

GPU CQ= 60, CPU RF=20

 

[iPhill]

Umrechnungsfaktor (videotoolbox = 100 - 2*x265)

Interessant! Da bin ich jetzt auch gespannt, woher die Berechnungsgrundlage dafür kommt.

 

[Tzunami]

Zur Sicherheit habe ich auch noch H265 getestet, und zwar wieder am Grenzbereich wo aus schön, Kacke wird.

CPU RF = 25 und bei GPU nach Formel CQ = 50
Auch hier ein deutlicher Qualitätsunterschied. Die Formel kann einfach nicht stimmen. Dann ist die CPU-Datei auch noch kleiner (4,5 zu 5,3 MB bei 30 sek.).^^

 

[dany2k]

Wow... Zuerst mal vielen vielen Dank euch allen für die schnellen, sehr brauchbaren und sehr informativen Antworten ! Super.
Ich werde da mal paar Vorschläge testen und dann schauen wir mal

Aber nochmals und Riesen großes herzliches Dankeschön !!!