m1 - h265 hardware encoder?

[Tzunami]

Hier noch mal ein Bild, da kann sich jeder seine eigene Meinung bilden. Beide Videos wurde mit 900 kbit/s kodiert.

Aus meiner Sicht gibt es zwei Varianten bei vergleichbarer Bildqualität.
Schnelles kodieren, aber die Datei muss dann unweigerlich größer sein. Das wäre dann GPU
Sehr langsames kodieren, aber dafür das beste, was bei H.265 an Kompression machbar ist. Das wäre dann CPU

 

[lisanet]

Hier noch mal ein Bild, da kann sich jeder seine eigene Meinung bilden. Beide Videos wurde mit 900 kbit/s kodiert.

tja... Intel halt. Kein Wunder.

Stand aber schon hier, ich zitiere mich mal selbst.

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.

 

[Tzunami]

tja... Intel halt. Kein Wunder.

Stand aber schon hier, ich zitiere mich mal selbst.

Das ist von einem Mac Studio, aber keine Angst, ich verrate deine Fehlannahme nicht weiter.

P.S.: Wenn ich jemand wäre, der nachtragend ist, würde ich wahrscheinlich jetzt mit sowas nebenbei einstreuen:

Für deinen beruflichen Werdegang hast du allerdings wenig Kenntnis, was

Sowas würde ich natürlich nie tun. Ich bin ja schließlich nicht nachtragend.
Habe ich eigentlich schon erwähnt, dass mir ein ehemaliger Arbeitskollege noch eine Entschädigung schuldet? Er hat sich 2001 „Die Mumie“ als DVD geliehen und dann verlegt.

 

[lisanet]

ich verrate deine Fehlannahme nicht weiter.

vielleicht wäre es hilfreich, deine Sig zu aktualisieren? Natürlich nur nachdem du konsequent weiter ignorierst, dass ich von "constant quality" spreche und du bitrate-gebundene Kodierungen erwähnst.

Ist aber nicht schlimm, ich verrate dein falsches Textverständnis nicht.

Edit:

Ach ja, nicht nur das mit dem Textverständnis scheint etwas zu holpern. Die Aussagen deines "Test" mit den 900 kbps encodings sind nicht so recht, naja, passend.

Erkläre doch bitte mal technisch, wie bei einem bitraten-gebundenen encoding folgende Aussage stimmen soll:

"Schnelles kodieren, aber die Datei muss dann unweigerlich größer sein. Das wäre dann GPU"

Konkret: wie soll die Datei "unweigerlich größer" werden?

 

[oneOeight]

Da anscheinend niemand den verlinkten Artikel in #23 gelesen hat, hier mal den Teil warum man CRF mit Constant Quality nicht ganz vergleichen kann:

CRF versus Constant QP

CRF is a “constant quality” encoding mode, as opposed to constant bitrate (CBR). Typically you would achieve constant quality by compressing every frame of the same type the same amount, that is, throwing away the same (relative) amount of information. In tech terminology, you maintain a constant QP (quantization parameter). The quantization parameter defines how much information to discard from a given block of pixels (a Macroblock). This typically leads to a hugely varying bitrate over the entire sequence.

Constant Rate Factor is a little more sophisticated than that. It will compress different frames by different amounts, thus varying the QP as necessary to maintain a certain level of perceived quality. It does this by taking motion into account. A constant QP encode at QP=18 will stay at QP=18 regardless of the frame (there is some small offset for different frame types, but it is negligible here). Constant Rate Factor at CRF=18 will increase the QP to, say, 20, for high motion frames (compressing them more) and lower it down to 16 for low motion parts of the sequence. This will essentially change the bitrate allocation over time.

 

[lisanet]

Da anscheinend niemand den verlinkten Artikel in #23 gelesen hat, hier mal den Teil warum man CRF mit Constant Quality nicht ganz vergleichen kann:

ich kenne den Artikel sogar sehr gut. Darum schreibe ich u.a das immer in Anführungszeichen.

 

[Tzunami]

vielleicht wäre es hilfreich, deine Sig zu aktualisieren?

Ähm: Mac13,2 | 16×3.2 GHz + 4×2.1 GHz | 48 Core | 64 GB | 2.0 TB NVMe | 5 TB HD

Natürlich nur nachdem du konsequent weiter ignorierst, dass ich von "constant quality" spreche und du bitrate-gebundene Kodierungen erwähnst.

Nachdem du weiter konsequent ignorierst, dass deine Umrechnungsformel falsch ist und man deshalb eine CF und eine CQ qualitativ nicht vergleichen kann, bleibt nur konstante Bitrate.

Erkläre doch bitte mal technisch, wie bei einem bitraten-gebundenen encoding folgende Aussage stimmen soll:

"Schnelles kodieren, aber die Datei muss dann unweigerlich größer sein. Das wäre dann GPU"

Konkret: wie soll die Datei "unweigerlich größer" werden?

Ist das jetzt dein Ernst? Man kann doch eindeutig an den Frames sehen, dass die Qualität bei 900 kbit bei CPU ein wesentlich besseres Bild liefert. Man müsste also, um die Qualität der CPU-Kodierung zu erreichen, unweigerlich die Bitrate erhöhen, was die Datei größer macht.

Wie das ganze bei "constant quality" aussieht, könnte man nur mit dem korrekten Umrechnungsfaktor bestimmen, den gibt es aber scheinbar nicht, denn wie man in #17 sieht, erhält man, mit deiner Formel, nicht mal annähernd dieselbe Qualität.

 

[Tzunami]

Ich habe mal H.264 verwendet, um einigermaßen zu ermitteln, wann die CF und CQ ungefähr die gleiche Qualität bieten. Das ganze erkennt man recht gut an der Blockbildung bei den Verläufen. Bei allen Bildern wurde die Belichtung erhöht (3,5), um die Blockbildung besser erkennen zu können.

Das ist die Umrechnungsformel, CF 20 zu CQ 60, die lisanet zur Verfügung gestellt hat (Herkunft, keine Ahnung). Bei der GPU sieht man starke Blockbindung. Die Qualität ist massiv schlechter. CPU = CF 20

CQ 75: Immer noch stärkere Blockbildung bei der unscharfen Schneeflocke.

CQ 80: Langsam erreicht man die Qualität der CPU-Kodierung, wobei man noch leicht höhere Blockbildung als bei der CPU-Kodierung erkennen kann.

Mittlerweile hat man fast die Qualität der CPU-Kodierung erreicht. Nun kommen wir zur Größe: CPU 17 MB, GPU 55 MB. Das könnte ich jetzt auch noch bei H.265 machen, aber ich glaube da wird das CF- zu CQ-Verhältnis ähnlich ausfallen.

 

[Tzunami]

So, auch noch mal H.265 bei CF20 und CQ 60. GPU hat eine erheblich schlechtere Qualität mit der Formel für die Videoboxumrechnung.

Selbst bei CF 80 kommt die GPU qualitativ nicht an die CPU ran.

Größe bei CF 20 (CPU) 9 MB
Größe bei CQ 80 (GPU) 26,2 MB und man ist noch nicht mal an der CPU-Qualität dran.

OK, man ist schnell fertig, aber dann ist man halt schon, von der Größe, im CPU H264 Bereich.

 

[spittix]

Erst mal vielen Dank für die vielen aufschlussreichen Erklärungen.
Wie kann ich denn prüfen/sicherstellen, dass ich die richtige Videotoolbox installiert habe?

 

[AgentMax]

Ich wüsste nicht das man das separat installieren kann. Teil vom Betriebssystem bzw. der App welche du zum wandeln benutzt.

 

[spittix]

Ich nutze Handbrake. Hatte verstanden, dass es verschiedene Versionen der Toolbox gibt. Ich würde einfach gern nachvollziehen, ob die angesprochenen Prüfungen verschiedener Optimierungsmöglichkeiten genutzt werden, oder nicht (Möglichst ohne visuelles Ausprobieren ).

 

[Tzunami]

Ich nutze Handbrake. Hatte verstanden, dass es verschiedene Versionen der Toolbox gibt. Ich würde einfach gern nachvollziehen, ob die angesprochenen Prüfungen verschiedener Optimierungsmöglichkeiten genutzt werden, oder nicht (Möglichst ohne visuelles Ausprobieren ).

Der Funktionsumfang unterscheiden sich wohl zwischen Intel und Apple Silicon. Zumindest kann ich auf meinem Mac Pro mit Xeon kein CQ aktivieren. Wie das bei einem Core Prozessor mit Quick Sync aussieht weiß ich nicht. Wie sich der Funktionsumfang zwischen Apple Silicon und Intel sonst unterscheidet, kann ich dir auch nicht sagen.

 

[Difool]

Erst mal vielen Dank für die vielen aufschlussreichen Erklärungen.
Wie kann ich denn prüfen/sicherstellen, dass ich die richtige Videotoolbox installiert habe?

Naja, gewusst wie bzw. achso:
https://trac.ffmpeg.org/wiki/HWAccelIntro#VideoToolbox

Video Toolbox
Work directly with hardware-accelerated video encoding and decoding capabilities.
https://developer.apple.com/documentation/videotoolbox

 

[spittix]

Das beantwortet leider meine Frage nicht. Ich habe die Recherchemaschine bereits bedient und die empfohlenen Seiten auch bereits gefunden.
Aber wie Handbrake die Videotoolbox ansteuert kann man dort nicht sehen. Auch in der Aktivitätsausgabe von Handbrake stehen die von lisanet angegebenen Details nicht (alle) drin...

 

[Tzunami]

Das beantwortet leider meine Frage nicht. Ich habe die Recherchemaschine bereits bedient und die empfohlenen Seiten auch bereits gefunden.
Aber wie Handbrake die Videotoolbox ansteuert kann man dort nicht sehen. Auch in der Aktivitätsausgabe von Handbrake stehen die von lisanet angegebenen Details nicht (alle) drin...

Hast du schon geschrieben, welchen Rechner du hast? Da die Videotoolbox Bestandteil von macOS ist, kommt es wahrscheinlich auch auf das System an.

 

[Tzunami]

Aber wie Handbrake die Videotoolbox ansteuert kann man dort nicht sehen.

Ob die Videobox arbeitet, sieht man wohl nur hier unter Media (und natürlich an der Geschwindigkeit):

 

[lisanet]

Das beantwortet leider meine Frage nicht. Ich habe die Recherchemaschine bereits bedient und die empfohlenen Seiten auch bereits gefunden.
Aber wie Handbrake die Videotoolbox ansteuert kann man dort nicht sehen. Auch in der Aktivitätsausgabe von Handbrake stehen die von lisanet angegebenen Details nicht (alle) drin...

Das kannst du nur dann zu 100% nachprüfen, wenn du den source code von Handbrake analysieren würdest.

Wie ich schon oben schrieb, hat damals Handbrake alla die notwendigen und sinnvollen settings verwendet und cih gehe davon aus, dass dies auch heute noch immer der Fall ist.

Ebenso wie dargestellt: du benötigst einen Apple Silicon Rechner und Handbrake muss als natives Apple Silicon binary vorliegen. Ein Intel-only binary hat nicht alle Funktionen.

Damals (vor rd 2 Jahren, als ich mich damit beschäftigt hatte) musste das binary auch auf einem Apple Silicon Rechner erstellt werden. Auf einem Intel-Rechner erstellt, werden die APIs nicht voll genutzt. Ob das durch andere compiler / linker /conditional compiling settings hätte geändert werden können, habe ich nie analysiert, denke aber schon.

Mein persönlicher Tipp:

Sicherstellen kannst du das nur, wenn du Handbrake auf einem Apple Silicon Rechner selbst installierst. Das ist aber nicht enduser-tauglich und erfordert etwas Know-How. Nein, eine Hilfestellung übers Forum gebe ich dafür nicht.

Warum dieser Tipp? Ich vermute aus den Postings hier im Forum, dass den Entwicklern von Handbrake zwar Macs zur Verfügung stehen, aber keine Apple Silicon Rechner, sondern nur Intel-Macs und/oder eben nicht die passenden compiler / linker / conditional compiling settings gewählt wurde.

Mit ffmpeg ist das nicht anders. Da kommt dann noch hinzu, dass du dich mit ffmpeg und seine x Parametern und Optionen genau auseinander setzen musst. Da gibt es keine presets. Du bist selbst für alles veranwortlich. Erg: es ist nicht enduser-tauglich. Ich kann dir eine funktionierende Kommandozeile liefern und stelle auch ein natives binary zur Verfügung _aber_ ich gebe darüber hinaus keinerlei Support oder Hilfestellung übers Forum, wenn du dich nicht hinreichend gut mit Terminal auskennst. Sonst wird das nämlich nur für beide Seiten sehr stressig und ärgerlich.

 

[spittix]

Ich habe ein MBP 16" mit M2 Max und habe Handbrake 1.7.1 installiert. Auf der Projektseite gibt's das nur als Universal Binary, nicht als AS-native Download.

Mein persönlicher Tipp:

Sicherstellen kannst du das nur, wenn du Handbrake auf einem Apple Silicon Rechner selbst installierst. Das ist aber nicht enduser-tauglich und erfordert etwas Know-How. Nein, eine Hilfestellung übers Forum gebe ich dafür nicht.

Mit installieren meinst Du Handbrake aus den Sourcen auf meinem Mac selbst compilieren?

 

[lisanet]

Ich habe ein MBP 16" mit M2 Max und habe Handbrake 1.7.1 installiert. Auf der Projektseite gibt's das nur als Universal Binary, nicht als AS-native Download.

Mit installieren meinst Du Handbrake aus den Sourcen auf meinem Mac selbst compilieren?

ja