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

[steve it]

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.

mit superfast offenbar (und beim visuellen Vergleich kann es einen Unterschied von den jeweiligen Szenen machen, z.B. schnelle Motive/Kameraschwenks, Details, ...); die Dateien sind ein gutes Stück größer (ca. 0,5 GB).

Die Jubler, auf die ich mich beziehe, nutzen i.d.R. kein ffmpeg (maximal indirekt). Die nutzen die VideoToolbox aus gängigen Programmen wie FinalCutPro X & Co. Daher passt dein ganzer Post nicht auf diese Jubler. Die nutzen das Hardware-Encoding so, wie es angeboten wird und nehmen dann als einzigen Maßstab die Encodinggeschwindigkeit.
H.264 ist übrigens ebenfalls noch interessant.

 

[AgentMax]

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.

Kannst mir mal sagen wie du das genau machst?
Ich will schon länger meine Sammlung neu codieren und h265 nehmen um Platt zu sparen. Aber bekomme nichts platzsparendes hin was irgendwie vergleichbar mit den h264 wäre.
Habe bisher immer mit Handbrake herum probiert.
Auf M1 oder auch GeForce 2060. war alles nicht berauschend.

 

[lisanet]

mit superfest offenbar.

Die Jubler, auf die ich mich beziehe, nutzen i.d.R. kein ffmpeg. Die nutzen die VideoToolbox aus gängigen Programmen wie FinalCutPro X & Co. Daher passt dein ganze Post nicht auf diese Jubler, die teilweise noch nicht mal wissen, was die VideoToolbox ist (wie ich schon angedeutet habe).

naja, zum einen hast du direkt auf mein Posting reagiert, mit deiner Jubler-Herabwürdigung und zum anderen finde ich es sehr gewagt, dass du dir eine Aussage über das Know-How von anderen erlaubst und selbst aber zugibst, dass du diese Dinge mit VT nicht kennst bzw. ausprobiert hast.

Und was meinst du denn mit "mit superfast offenbar"?

Bist du der Ansicht, dass die superfast-Option einen visuell irgendwie wahrnehmbaren Einfluss auf die Qualität hat, die mit crf eingestellt wird? Falls ja, begründe doch mal. Du brauchst dabei aber bitte nicht die Aufstellung der in den diversen presets zusammengefassten Parameter nennen. Die kenne ich. Mir geht es um die visuell wahrnehmbare Qaulität.

BTW, superfast habe ich deswegen heran gezogen, da selbst mit dieser sehr geschwindigkeitsoptimierten Einstellung, x265 drastisch länger benötigt ohne eine visuell wahrnehmbare Verbesserung zu erzielen.

Edit:

Noch was. Da du ja weiterhin User, die FCP verwenden als Jubler bezeichnest, eine kleine Info für dich: FCP wird mit an Sicherheit grenzender Wahrscheinlichkeit die API des videotoolbox-Frameworks verwenden. Genauso macht es auch ffmpeg. Hinischtlich der Kodierung der frames sind also beide Programme auf gleichen Wegen unterwegs. Natürlich sind dann die weitern Verarbeitungsschritte anders implementiert. Hinsicht der Qualität aber sind, entgegen deinen Behauptungen, aber bei Programme durchaus vergleichbar, da sie die gleichen API verwenden.

 

[lisanet]

Kannst mir mal sagen wie du das genau machst?
Ich will schon länger meine Sammlung neu codieren und h265 nehmen um Platt zu sparen. Aber bekomme nichts platzsparendes hin was irgendwie vergleichbar mit den h264 wäre.
Habe bisher immer mit Handbrake herum probiert.
Auf M1 oder auch GeForce 2060. war alles nicht berauschend.

Ich mach das mit ffmpeg. In den derzeitigen snapshots ist mein patch hinsichtlich der constant quality und der b-pyramid enthalten. Du benötigst aber eine nativ für den M1 kompilierte Version. Ein Intel-Binary über Rosetta bringt nichts.

Meinen erneuten patch für die rd. 420 fps muss ich erst noch kurz zusammenfassen und an die devel-Mailingliste senden. Dann dauert es aber erfahrungsgemäß noch eine ganze Zeit (durchaus Monate), bis der in die offiziellen sourcen kommt.

Falls du interessiert bist, kann ich dir aber mein binary zur Verfügung stellen (habe ich anderen Usern hier auch schon gegeben).

Falls du mit ffmpeg dann kodieren willst, kann ich hier ja mal die Befehlszeile dazu posten und ein paar Erklärungen zu den jeweiligen Optionen geben.

 

[AgentMax]

Ja. Wäre mal interessant und den Versuch wert.

 

[steve it]

Noch was. Da du ja weiterhin User, die FCP verwenden als Jubler bezeichnest, eine kleine Info für dich: FCP wird mit an Sicherheit grenzender Wahrscheinlichkeit die API des videotoolbox-Frameworks verwenden. Genauso macht es auch ffmpeg. Hinischtlich der Kodierung der frames sind also beide Programme auf gleichen Wegen unterwegs. Natürlich sind dann die weitern Verarbeitungsschritte anders implementiert. Hinsicht der Qualität aber sind, entgegen deinen Behauptungen, aber bei Programme durchaus vergleichbar, da sie die gleichen API verwenden.

Ich nutze selber FCPX. Nur eben nicht die VideoToolBox. Ich exportiere den fertigen Film in ProRes um den Apple Encoder (egal ob Software oder VT) zu umgehen und dann mittels x264 zu encodieren (ab und an auch x265).
Mit Jubler meine ich die, die mit den Benchmarks posen (wie ich oben schrieb, gibt es sogar Fälle, in denen Jubler Architekturen vergleichen und nicht merken, dass auf Architektur A der HardwareEncoder genutzt wird und auf Architektur B auf der CPU encodiert wird).

Übrigens sind deine Dateien ein gutes Stück größer. Du bestätigst also eher meine Aussagen als sie zu widerlegen (bei unklarem Ausgangsmaterial).

 

[lisanet]

Übrigens sind deine Dateien ein gutes Stück größer. Du bestätigst also eher meine Aussagen als sie zu widerlegen

sorry. Ich rede von visuell wahrnehmbarer Qualität. Darum geht es.

Aber wie schon oft genug gesagt, wenn du Dateigröße als ein maßgebendes Kriterium heranziehst, dann tu es. Mir ist die visuelle Qualität wichtiger. Und die ist rundum bei allen Videos die ich kodiere visuell vergleichbar. Hinzu kommt der Vorteil der drastisch höheren Geschwindigkeit.

Aber ich seh schon, du legst halt eher wert auf Dateigröße. Kein Problem für mich.

 

[tocotronaut]

Es gab mal ein Programm, das wirklich gute ansätze hatte...
Videomonkey.

Das hatte einen Knopf: Limit input Parameter to output.
Das hat alle Videos mit der gleichen Auflösung/Farbtiefe/Framerate wie beim Original konvertiert nur halt eben im neuen Format.

Die neu konvertierten Dateien waren dann immer auch etwas kleiner.
Allerdings muss ich gestehen, dass ich die Visuelle Qualität nur Stichprobenartig und sehr rudimentär überprüft hatte...

 

[steve it]

sorry. Ich rede von visuell wahrnehmbarer Qualität. Darum geht es.

Aber wie schon oft genug gesagt, wenn du Dateigröße als ein maßgebendes Kriterium heranziehst, dann tu es. Mir ist die visuelle Qualität wichtiger. Und die ist rundum bei allen Videos die ich kodiere visuell vergleichbar. Hinzu kommt der Vorteil der drastisch höheren Geschwindigkeit.

Aber ich seh schon, du legst halt eher wert auf Dateigröße. Kein Problem für mich.

Mir geht es um beides. Das Gesamtpaket.
Aus meiner Sicht gibt es drei Aspekte: Encodingdauer, Qualität und Dateigröße => und in den "Tests" bzw. Vergleiche, über die ich mich ärgere, wird nur auf den Aspekt Encodingdauer geachtet.
Und da ich nur ab und an ein Video encodiere, sehe ich für mich noch weniger einen Vorteil bei der VideoToolBox. In deinem Beispiel läuft das auf der CPU mit 50 Fps. Ist doch ziemlich gut (ich kann mich noch an ganz andere Zeiten erinnern). Klar, gegen die VT ist es langsam...

Ich habe aber gelernt, dass es Verbesserungen gibt, die mir nicht geläufig waren (dank deines Patches).

 

[lisanet]

@AgentMax

Den Link zum aktuellen binary von ffmpeg schicke ich dir heute abend per PM (bin gerade mobil auf dem iPad unterwegs)

Hier erst mal die Befehlszeile, die ich nuzte für ein FullHD-Ausgangsmaterial. Ab und an ergänze ich die auch noch um Optionen zur Kennzeichnung der Landessprache der Audiospur. Das habe ich mal weg gelassen.

ffmpeg -i input.mp4 -c:v hevc_videotoolbox -prio_speed 1 -vtag hvc1 -bf 1 -q:v 60  -g 240 -vf crop=1920:800:0:140  -c:a aac -b:a 256k -ac 2 -af aresample=matrix_encoding=dplii:lfe_mix_level=0.707 output.mp4

Zu den einzelnen Optionen

-i input.mp4 Ausgangsvideo

-c:v hevc_videotoolbox das wählt als codec HEVC(=h265) mit videotoolbox als encoder.

-prio_speed 1 ist die Option meines neuen Patches und schaltet die Priorisierung der Geschwindigkeit ein. -prio_speed 0 oder ganz ohne prio_speed ist ohne diese Geschwindigkeitsoptimierung und entspricht den derzeitigen offiziellen snapshots.

-vtag hvc1 setzt als FourCC "hvc1", was Apple verlangt um HEVC sauber / problemlos wiedergeben zu können. Unbedingt angeben. ffmpeg nimmt leider standardmäßig "hev1".

-bf 1 schaltet B-Frames (b-pyramid) ein. Unbedingt angeben.

-q:v 60 verwendet constant quality anstelle von nur constant bitrate. Der Wert läuft von 0 - 100, wobei 100 die höchste Qualität darstellt. Es ist vergleichbar mit -crf bei x264/x265. -crf 20 entspricht in etwa -q:v 60.

-g 240 setzt die GOP-Size auf 240 frames. Ohne diese Option setzt der M1-encoder die GOP-Size automatisch je nach Bedarf. Diese Option bringt ca. 3% - 5% geringere Dateigrößen. Der Wert sollte 10 * Bildfrequenz sein. Nachteil: Der schnelle Suchlauf ist nicht mehr ganz so flüssig.

-vf crop=1920:800:0:140 cropt das Video auf 1920:800 mit gleichem Wert von 140 oben und unten


-c:a aac -b:a 256k -ac 2 -af aresample=matrix_encoding=dplii:lfe_mix_level=0.707 sind die Parameter für Audio, die ich gerne nutze. Wenn du die vorhandene Audiospur lediglich kopieren willst, nimm -c:a copy, wobei es immer zu empfehlen ist, um die Kompatibilität mit Apple Geräten zu haben, dass AAC verwendet wird, oder AC3 5.1 mit max 448 kbps.

Ich verwende gerne AAC 256 in einem Dolby Pro Logic II Downmix mit einem zusätzlichen Mix des LFE/Subwoofer-Channels. Das ist der Teil mit -af aresample=matrix_encoding=dplii:lfe_mix_level=0.707. Für Soundbars mit Subwoofer oder Surround-Headphones oder andere 2.1 Setups, ist das echt eine hörbare Verbesserung. DPL II trennt die Kanäle sogar recht gut auf 5.1 Setups. Probiere es einfach mal aus.
Ich möchte es mittlerweile nicht mehr missen, da bei einem 2.1 Setup die Dolby Decoder einen 5.1 Audiostream zwar schön downmixen aber halt nur nach DPL II ohne den Subwoofer-Channel. Ein vorhandener Subwoofer übernimmt dann nur die tieferen Freqs, aber der eigentliche Wumms fehlt. Daher kodiere ich meine Videos eben gleich in den DPL II downmix mit LFE.

output.mp4 ist das Ausgabefile.

Vorhandene h264 Ausgangsdateien (1920x1080, 24p, 7500 kbps, AC3 640 kbits, mp4 container) transkodiere ich damit mit ca 420 fps.

 

[AgentMax]

Zu ffmpeg bin ich noch nicht gekommen, aber ich habe jetzt heute mein 16" MBP mit M1 Pro bekommen.

Bei der gleichen Datei (FullHD, h264) welche das MBP umwandeln soll (videotoolbox h265 10 bit), ist es massiv langsamer als
mein M1 Mini.
Der Mini macht so 160-170fps. Das MBP bleibt bei ca 60fps.

 

[biro21]

Zu ffmpeg bin ich noch nicht gekommen, aber ich habe jetzt heute mein 16" MBP mit M1 Pro bekommen.

Bei der gleichen Datei (FullHD, h264) welche das MBP umwandeln soll (videotoolbox h265 10 bit), ist es massiv langsamer als
mein M1 Mini.
Der Mini macht so 160-170fps. Das MBP bleibt bei ca 60fps.

Willkommen im Club.

Mit der normalen ffmpeg-Version ist es nicht besser, die Version von @lisanet ist schon einmal eine deutliche Verbesserung, aber immer noch nur 50% der Leistung auf den M1 Macs.

Vor einer Weile habe ich diese Ergebnisse hier im Forum gepostet und wurde von ein paar Apologeten massiv angegangen... Jetzt, knapp 6 Wochen später, hat sich leider immer noch nichts zum Besseren verändert.

 

[lisanet]

Jetzt, knapp 6 Wochen später, hat sich leider immer noch nichts zum Besseren verändert.

tja, die Mac-Entwickler im open source Bereich sind dünn gesät.

Ich hätte schon noch ein paar Ideen, die ich mit einigen API-Calls des Videotoolbox-Frameworks mal ausprobieren möchte, allerdings bräuchte ich da einen M1P, den ich nicht habe (und auch nicht beabsichtige mir demnächst zu kaufen).

Z.Bsp. kann man die GPU angeben, die man verwenden will. Und da der M1P bzw. M1M mehrere encoder engines hat, wäre das ein Ansatz. Allerdings müsste man dann auch wahrscheinlich das Thread-Handling entsprechend anpassen. Und da wird's dann eher anspruchsvoll und ohne Dev-Rechner schwer.

 

[biro21]

Hoffe du weißt dass es Leute gibt die deine Bemühungen sehr zu schätzen wissen. Kann dir aber leider nicht wirklich weiterhelfen - außer dass ich gerne bereit bin zu testen.

Seltsamerweise ist ja so, dass selbst Compressor von Apple manche Konvertierungen auf dem M1P langsamer erledigt als auf dem M1.

 

[sammy2k8]

Guten Abend

Mit Interesse lese ich die Beiträge hier zum aktuellen Apple M1 & Handbrake Thema, sowie wie auch unter Reddit und dem MacRumors Forum über die Leistungen der Pro und Max SOCs von Apple. Speziell interessiert mich persönlich die Leistung der "Hard,- & Softwareencodierung" der neuen Geräte.
Denn kurz gesagt bin ich selbst auf der Suche nach einem neuen "Powerhorse" dass einen 2 Jahre alten PC mit Intel 10900 Prozessor 6900XT & 3070 RTX (Linux) und ein MBP 16" (maxed out) ersetzen könnte.

Wie alles im Leben gibt es nicht die ultimative Wollmichsau. Nur für die Encodierung betrachtet, könnte ein Ryzen oder ein Threadripper (HEDT Bereich) mehr leisten, als das vorhandene Equipment oder eben ein M1 Pro/Max (Softwareendcodierung). Von der Skalierung des ffmpeg Codec mal abgesehen, (optimaler Wert bei ca. 22 Cores) zählen eben auch Lautstärke und Strombedarf in einen nicht produktiven Haushalt. -> Die Zeit die dann benötigt wird, spielt hier auch nur eine unterordenete Rolle solange es nicht gerade 17 Stunden für ein gutes/perfektes Ergebnis sind.

So damit der Beitrag nicht ganz abschweift, würde ich auch gerne meine eigenen Erfahrungen zum laufenden Thema beitragen:

Und zwar ganz spezifisch zu Hard,- Softwareencodierung und deren Qualität. In eigenen dokumentierten Versuchen mit dem PC wie auch mit dem Mac Computer (Intel QuickSync, AMD GPU (ToolBox) Nvidia NVENC, sowie Apple T2 Chip) habe ich von unterschiedlichen UHDBDs ganze Filme und Teilsequenzen jeweils Hard,- und Software encodiert. Weiter deren Dateigrösse, Qualität und Abweichungen zum Original sowie unterienander verglichen.

Die kurze Antwort: Nichts kam an die Qualität der Softwareencodierung heran. Wobei hier in einem Beitrag geschrieben wurde das der Nvidia Encoder noch annähernd brauchbare Ergebnisse liefert. Dem kann ich, zusammen mit Apples T2 Chip erwähnt, auch zustimmen!

Doch für was ist die Zustimmung genau und was ist mit brauchbar gemeint? Da trennen sich, wie immer, die Anforderungen und Geschmäcker.
Für Streaming, Mobile Devices und Internetvideos (YT und Co.) sind die hardwareencodierten Videos eine Gute und vor allen Dingen schnelle Sache.
Wer die bestmögliche Qualität archivieren oder aus seinem Quellmaterial ziehen möchte, kommt an der Softwareencodierung (h.264/h.265/AV1) nicht vorbei.

Diese Aussage ist der letzte Stand von mir mit der bestehenden Hardware. Und im Sinne als Filmfan / Enthusiast -> Nicht für die produktive/produzierende Umgebung (ProRes und Co.). Es gab noch keine Möglichkeit die aktuelle Mediaengine von Apple auszuprobieren und dem Vergleich zu unterziehen. Es würde mich sehr interessieren!

Die Software und entsprechendes Material habe ich hier zusammen getragen gehabt (sorry im vorraus, dass der Eintrag noch immer nicht fertig gestellt ist - das Ganze nimmt recht viel Zeit in Anspruch):
Der Codec Beitrag

Mich persönlich reizt auch das Leistung/Watt Verhältnis der neuen SOC in diesem Bezug (Softwareencodierung um einiges schneller, bei nur einem Drittel des Strombedarf...).

Ich bin auf eure Meinugen und Antworten gespannt und falls es jemanden mit einem aktuellen M1 Pro/Max jucken sollte, selbst so einen Vergleichstest durchzuführen wäre ich mehr als Dankbar!

 

[lisanet]

Ich habe deinen Beitrag nur kurz überflogen. Ich habe da allerdings auch wieder oft nur die üblichen pauschalen Aussagen gefunden (Software gut, Hardware schlecht) und auch keine Begründung, warum nun durch eine lange dauernde Softwarekodierung die visuelle Qualität besser werden soll, als bei in Hardware gegossenen Routinen, besonders wenn man bedenkt, dass die Zeit nahezu durchgehend für ein kleinere Dateigröße verwendet wird und nicht für visuelle Qualität. Kleinere Dateigrößen sind kein Merkmal besserer visueller Qualität.

Zudem zwei kurze Anmerkungen zu den "Fakten".

Zu Fakt 1: Hardwareencoding ist nicht starr, sondern kann durch Firmwareupdates der Hardware durchaus verändert werden.

Zu Fakt 2: Hardwareencoding erlaubt durchaus das Verändern von Parameter. Die Frameworks von z.Bsp VideoToolbox geben dir da gerne Auskunft.

 

[sammy2k8]

Hallo lisanet

Danke für deinen Beitrag. Natürlich muss man hier Unterhaltungen relativieren - sprich einfach halten. Und natürlich gilt das Prinzip der Videoencodierung für den Anwender auf deren Anforderung und Bedürfnis. Manche wollen die Dateien so klein wie möglich haben mit akzeptabler Einbuse der Qualität. Manche brauchen es in einem bestimmten Format damit es für ihre Zwecke dienlich ist usw.

Da ich schon selbst schrieb, und das auch Belegen kann, ging es mir um die visuelle Ausgabequalität das ist richtig. Da spricht auch nicht dagegen - weils einfach mal so ist. Egal welche Formel, Theorie und Befehle dahinter stehen - der Haken steckt im Detail wie du schreibst - müsste jeder der maximale Qualität will für jeden Punkt und Codec sowie HW Infos lesen. Wenns die nur immer gäbe...

Nebenbei:
Es liegt auch mitunter an der Aussage der "Erfinder/Macher" der Codecs - wenn etwas Neues auf den Markt stossen soll sprechen sie selbst in ihren Hauptargumenten von verbesserter Komprimierung bei gleicher oder höherer Qualität (visuell was sonst!?), mehr Bewegungsmatritzen etc etc.
Der Endanwender liest natürlich nur "bessere Qualität" bei "weniger Platzbedaf" für den Rest hat er kein Auge oder Sinn.

Der Beitrag sollte genau zu solch einer Unterhaltung führen. Zusammen mit dem Eintrag der eigenen Sammlung - auch als Austausch. Kein Bashing falls es so rüber kam.

Fair muss man sein und sagen: HW und SW Encodierung mit den Standardprofilen wie sie OOB kommen (Handbrake, DVDFab, AVidemux, VodmX usw. zeigen trotzdem genau meine Beobachtungen auf. Und ja auch mit der SW Encodierung kann man es verhauen - wenn es um die visuelle Ausgabe geht.

Pauschal kann ich auch schreiben dass das Ergebnis von Videos heute, die per HW Encoder verarbeitet werden, viel viel besser geworden sind als noch vor vielen Jahren.

Ich stimmte dir zu, theoretisch wäre die HW Encodierung nicht starr. Fakt ist aber das praktisch keiner der geneigten Hersteller Firmwareupdates für seine GPU Karten zu diesem Thema anbietet. Fakt ist auch das die HW Engines praktisch nirgends richtig beschrieben werden, wenn ich mich dafür interessiere. (Wir nehmen hier mal die Quadro (selten) und professionellen Beschleunigerkarten heraus.)

Stimmt VideoToolBox ist einer der wenigen HW Encoder die eine entsprechende Quelle anbietet indem man deren Unterstützung, Formate, Befehle etc. nachlesen kann und auch weiter gepflegt wird. Intel hatte das für QuickSync auch mal, hat sich nie weiter entwickelt. Handbrake hat die paar raren QSV Befehle längst schon nachlesbar hinterlegt.

Du wirst nur allzugut selbst wissen das zwischen Software (und Befehle) und die HW Unterstützung ein Unterschied liegt. Was kann der T2 Chip eigentlich tatsächlich alles? Oder was kann die Mediaengine meiner AMD Karte aus dem Jahre 2021? (Ich spreche nicht von der reinen Codecfunktion, sondern Matritze, Bewegungserkennung, Farbformate etc. -> Ich kann ja im Handbrake oder ffmpeg cli Befehle mitgeben wie ich möchte, wenns die HW nicht kann wird es nicht umgesetzt ... was bringt mir das? Die Stunden und Fülle von Tabs im Browser kenne ich selbst - und Endet oft mit irgendwo gelesenen waaagen Vermutungen und Aussagen. Try n Error wäre dann das Letzte. Wer macht das?

Schlussendlich arbeitet der Benutzer auf sein Ziel hin das er für sich hat. In meinem Beispiel wars die visuelle Ausgabequalität. Die sich bei der HW Encodierung auch optimieren lässt ganz gewiss, den faktischen Zeitgewinn der durch HW Encodierung einhergeht lässt sich auch nicht leugnen.

Es würde mich interessieren wie gut eben die neue Engine in den Apple Geräten ist, du selbst kannst dazu keine fundierte Aussage liefern oder?

 

[tocotronaut]

Hardwarekodierung ist schnell und effizient.

Aber irgendwann vor jahren, (als H.264 eingeführt wurde) hatte ich schonmal gelesen, dass dabei die Genauigkeit gelegentlich auf der Strecke bleibt...
Insbesondere bei definierten Signalen (z.b. die kamera eines Smartphones) kann auch die Qualität klasse sein. Keine Frage.

Aber ich vermute auch dass Software bei unterscheidlichen Eingangssignalen/Rohdaten bessere Qualität liefert (oder besser liefern kann, wenn man sie richtig einstellt)

Zu Fakt 1: Hardwareencoding ist nicht starr, sondern kann durch Firmwareupdates der Hardware durchaus verändert werden.

Zu Fakt 2: Hardwareencoding erlaubt durchaus das Verändern von Parameter. Die Frameworks von z.Bsp VideoToolbox geben dir da gerne Auskunft.

1 halte ich für zu kompliziert. Damit kann man vor allem fehler bereinigen.

2 halte ich für vergleichsweise starr.
Man kann neue Parameter in Software durchaus flexibler und schneller einführen und ändern als in Hardware.

 

[lisanet]

Aber irgendwann vor jahren, (als H.264 eingeführt wurde) hatte ich schonmal gelesen, dass dabei die Genauigkeit gelegentlich auf der Strecke bleibt...
Insbesondere bei definierten Signalen (z.b. die kamera eines Smartphones) kann auch die Qualität klasse sein. Keine Frage.

Aber ich vermute auch dass Software bei unterscheidlichen Eingangssignalen/Rohdaten bessere Qualität liefert (oder besser liefern kann, wenn man sie richtig einstellt)

... vor Jahren. Da hat sich seither einiges getan. Ich war auch mal so drauf, dass ich glaubte, dass Hardwareencoding nicht mit Software-Encodern mithalten könne.

Doch ich habe mich selbst davon vergewissert, dass ich mittlerweile mit dem M1 und dessen Hardware-Encoding eben _visuell_ rundum gleichwertige Ergebnisse erhalte, wie mit Software. Der Zeitpunkt war derjenige, als es möglich war, nicht nur constant bitrate zu verwenden, sondern b frames, b-pyramid, und constant quality. Die alten Berichte von "vor Jahren" waren damals berechtigt, sind aber nun nur noch Geschichte über "es war einmal... ".

Und es scheint auch hier so wie bei vielen anderen Themen: da ist viel Wissen von vor vielen Jahren vorhanden, wenig detaillierte Kenntnisse über die aktuellen Möglichkeiten die Frameworks bieten und auch ein großer Schuss an Glauben, dass Software ja immer besser sein müsse. Messtechnisch kann dies gut sein. Visuell nicht.

Wie dem auch sei, ich weiß was ich für Patches an ffmpeg und Handbrake vorgenommen habe und was sie bewirken. Ich erfreue mich an der Qualität bei gleichzeitiger drastischer Performancesteigerung. Die Dateigrößen spielen für mich da keine Rolle. Und hinsichtlich der Dateigrößen bin ich da also genauso drauf, wie die Audio-Enthusiasten, die Hi-Res 24/192 bevorzugen.

Mehr als hier ab und an mal an den alten, überkommenen Glaubensätzen rütteln, will ich nicht. Wer Zeit hat und meint, dass er dann mit x265 und preset veryslow, Unterschiede sehen könne zu entsprechende cq settings von Videotoolbox, bitte, der soll es ruhig tun. Schön wäre dann aber auch, wenn man das dann nicht als die einzige Wahrheit hinstellen würde.

 

[oneOeight]

Vielleicht sollte man nicht vergessen, dass solche Algorithmen Worst, Average und Best Case haben.
Interessant sind doch meist dunkle Flächen und die Klötzchenbildung dort.