m1 - h265 hardware encoder?

Tzunami schrieb:
Die Formel kann einfach nicht stimmen.
Zum Vergrößern anklicken....

Es ist ja auch nur ein Anhaltspunkt. x265 ist logaritmisch, videotoolbox nicht. Darum sprach ich auch von x265 = 20 und videotoolbox = 60. Es geht doch auch nicht um die Formel in irgendeiner MAthematik, sondern um die oft geäußerte Behauptung, das ein Hardware-Encoder schlechtere Qualität liefert. Das ist halt nicht so.

Wenn man natürlich unterschiedliche Werte hinsichtlich einer "constant quality" heranzieht, dann kriegt man natürlich unterschiedliche Ergebnisse.

Aber du kannst auch weiterhin Software nehmen. Ich weiß, wie ich encode, was ich programmiert habe, was deine Begrifflichkeiten bedeuten und wie die Qualitäten sind.

Und da für mich bei Audio die Dateigröße keine Rolle spielt, sondern die hörbare Qualität, so spielt für mich auch bei Video die visuelle Qualität eine Rolle. Du darfst gern bei deinem Glauben an x265 bleiben.
 
lisanet schrieb:
Es ist ja auch nur ein Anhaltspunkt. x265 ist logaritmisch, videotoolbox nicht. Darum sprach ich auch von x265 = 20 und videotoolbox = 60. Es geht doch auch nicht um die Formel in irgendeiner MAthematik, sondern um die oft geäußerte Behauptung, das ein Hardware-Encoder schlechtere Qualität liefert. Das ist halt nicht so.

Wenn man natürlich unterschiedliche Werte hinsichtlich einer "constant quality" heranzieht, dann kriegt man natürlich unterschiedliche Ergebnisse.

Aber du kannst auch weiterhin Software nehmen. Ich weiß, wie ich encode, was ich programmiert habe, was deine Begrifflichkeiten bedeuten und wie die Qualitäten sind.

Und da für mich bei Audio die Dateigröße keine Rolle spielt, sondern die hörbare Qualität, so spielt für mich auch bei Video die visuelle Qualität eine Rolle. Du darfst gern bei deinem Glauben an x265 bleiben.
Zum Vergrößern anklicken....
Das Problem ist doch aber, dass man keine gemeinsame Messbasis für diese Aussage der „gleichen Qualität“ hat. Klar man kann den Regler hochschieben und erhält bessere Qualität, aber eben auch eine größere Datei. Das kann ich aber auch beim RF Regler machen.
Hier geht es ja auch nicht um die Qualität an sich, sondern um die Qualität im Verhältnis zur Dateigröße.

Ich sehe Moment nur die konstante Bitrate um einen Vergleich zwischen GPU- und CPU-Kodierung zu treffen und da schneidet meines Wissens die GPU immer schlechter ab.
 
Tzunami schrieb:
Das Problem ist doch aber, dass man keine gemeinsame Messbasis für diese Aussage der „gleichen Qualität“ hat.
Zum Vergrößern anklicken....

und wie machen dann alle Projekte eine Aussage hinsichtlich der visuellen Qualität Ihrer Encoding-Ergebnisse, wenn es deines Erachtes keine Messgrößen gibt?

Klar gibt es Messgrößen. Und damit wird dann eben diese visuelle Qualität verglichen. Dateigröße hat aber nichts mit einer visuellen Qualität zu tun.

Sieh es doch mal so:

Wenn es wie du behauptest, keine Meßgrößen gäbe, die visuelle Qualität zu beurteilen, wie macht dann x265 die Skala mit crf?

Da x265 (und auch alle anderen Encoder) Paramter besitzen, welche nach Aussage der jeweilgen Encoder-Entwickler die visuelle wahrgenommene Qualität beschreiben, muss es wohl eben doch solche Messgrößen geben.

Und zu Effizienz:

Wenn man Effizienz als Verhältnis von visueller Qualität zu Zeitaufwand ansieht, dann haben Hardware-Encoder die Nase vorn. Bezieht man Effizienz auf visuelle Qualität zu Dateigröße dann hat Software-Encoding oft die NAse vorn.

Beides sagt aber eben nichts über die visuelle Qualität an sich aus.

Edit:

Man kann auch in der Doku zu x265 nachlesen, dass die von dir genannten Begrifflichkeiten dazu dienen, bei einer gegebenen Qualität per crf, eine möglichst geringe Bitrate zu verwenden. Diese Dinge haben also eben keinen Einfluss auf die Qualität, sondern auf die dafür aufgewendete Bitrate.

https://x265.readthedocs.io/en/stable/presets.html

When you use slower presets, x265 tests more encoding options, using more computations to achieve the best quality at your selected bit rate (or in the case of –crf rate control, the lowest bit rate at the selected quality).

Und zu wahrgenommener visuellen Qualität beschreibt die Doku zu x265 auch zwei der verwendbaren Messgrößen: psnr und ssim

The psnr and ssim tune options disable all optimizations that sacrafice metric scores for perceived visual quality (also known as psycho-visual optimizations). By default x265 always tunes for highest perceived visual quality but if one intends to measure an encode using PSNR or SSIM for the purpose of benchmarking, we highly recommend you configure x265 to tune for that particular metric.
 
Zuletzt bearbeitet:
Tzunami schrieb:
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.
Zum Vergrößern anklicken....

ich weiß nicht wie handbrake das macht, ich habe vor rd 2 Jahren einen Patch zu ffmpeg beigetragen, mit dem für videotoolbox, diverse Möglichkeiten der API ansprechbar werden. Z.Bsp auch pyramidale b-frame, individuelle GOP-size und "prefer-speed". Natürlich muss man diese Parameter explizit mit angeben.

Was mich nur wundert ist, dass Handbrake das nun anders macht. Damals war das definitv nicht der Fall und auch Handbrake hat pyramidale b-frames automatisch aktiviert. Die API zu videotoolbox lässt auch gar nichts anderes zu, als eben pyramidale b-frames.

Das alles gilt aber auch, wie schon weiter oben erwähnt, nur für Apple Silicon Rechner und dann auch nur für native ARM-binaries.
 
lisanet schrieb:
Klar gibt es Messgrößen. Und damit wird dann eben diese visuelle Qualität verglichen. Dateigröße hat aber nichts mit einer visuellen Qualität zu tun.
Zum Vergrößern anklicken....
Also ich sehe hier genau zwei Messgrößen die direkt vergleichbar wären und das sind Bitrate und Bildqualität. Die Bildqualität lässt sich aber für den „Normalo“ ohne aufwendige Messmethoden schlecht als Grundlage für eine eine Beurteilung heranziehen. Der Schieberegler bringt wenig, solange kein exakter Umrechnungsfaktor bekannt ist Ein Liter und ein Kilo sind schließlich auch nur identisch, wenn es sich bei dem Liter um Wasser handelt.

Die Bitrate jedoch kann bereits Unterschiede in der Qualität zwischen GPU- und CPU-Encoder sichtbar zeigen. Wenn man zum Beispiel im Grenzbereich der Bitrate kodiert, kann man anhand der Blockbildung grob beurteilen, welcher Encoder ein schlechteres Bitraten/Qualitätsverhältnis aufweist.
 
Zuletzt bearbeitet:
Tzunami schrieb:
Also ich sehe hier genau zwei Messgrößen die direkt vergleichbar wären und das sind Bitrate und Bildqualität. Die Bildqualität lässt sich aber für den „Normalo“ ohne aufwendige Messmethoden schlecht als Grundlage für eine eine Beurteilung heranziehen.

Die Bitrate jedoch kann bereits Unterschiede in der Qualität zwischen GPU- und CPU-Encoder sichtbar zeigen. Wenn man zum Beispiel im Grenzbereich der Bitrate kodiert, kann man anhand der Blockbildung grob beurteilen, welcher Encoder ein schlechteres Bitraten/Qualitätsverhältnis aufweist.
Zum Vergrößern anklicken....

wir drehen uns im Kreis: du redest von einem Verhältnis Größe/Qualität, ich von Qualität alleine.

Ich habe ja auch schon geschrieben, dass Größe/Qualität bei x265 besser ist als bei videotoolbox, dafür ist das Verhältnis Zeit/Qualität bei videotoolbox besser. Beides hat aber nichts zu tun mit der visuellen Qualität an sich.

Wenn das für dich aber das Verhältnis Größe/Qualität gleichbedeutend mit Qualität ist... bitte sehr. Das kann zwar logisch gar nicht sein, aber du willst es wohl so. Dann bleibe bei deiner Ansicht, dass Software-encoding eine bessere Qualität hätte als Hanrdware-Encoder.

Ich lasse das jetzt hier im Forum sein, mit Tipps zu videoencoding. Mir wird diese Ideologie "Software gut - Hardware schlecht" zu blöd. Zu oft will man hier an irgendwelche uralten Mythen glauben und zeigt sich gegenüber Entwicklungen abweisend.
 
lisanet schrieb:
wir drehen uns im Kreis: du redest von einem Verhältnis Größe/Qualität, ich von Qualität alleine.
Zum Vergrößern anklicken....
Dann würde ich dir unkompliziertes Video empfehlen.

Das man mit H.264 und H.265 nahezu identisch Qualität, im Vergleich zu unkomplizierten Video erreichen kann, sollte wohl klar sein. Stell einfach den Regler auf Maximum. Man verwendet aber einen Codec um Video bei annähernd gleicher Qualität, bestmöglich zu komprimieren. Nur aus diesem Grund gibt es überhaupt Codecs.

Wenn Größe keine Rolle spielen würde, warum dann auch nur eine Sekunde für das kodieren verschwenden?
 
Zuletzt bearbeitet:
Tzunami schrieb:
Dann würde ich dir unkompliziertes Video empfehlen.

Das man mit H.264 und H.265 nahezu identisch Qualität, im Vergleich zu unkomplizierten Video erreichen kann, sollte wohl klar sein, man stellt einfach den Regler auf Maximum. Man verwendet aber einen Codec um Video bei annähernd gleicher Qualität, bestmöglich zu komprimieren. Nur aus diesem Grund gibt es überhaupt Codecs.
Zum Vergrößern anklicken....

Okay, dann eben unsachlich weiter, wenn du mit dieser Empfehlung anfängst und mir Unwissenheit über die Gründe der Entwicklung von Videocodecs unterschiebst, wobie ich dir unterstelle, dass du "unkomprimiertes Video" meintest. Das kann ich auch:

Es gibt User, die freuen sich darüber, dass das encoding in hevc einer FullHD BluRay/Filmes mit DD-Ton mit 520 fps abläuft, weil sie keine Lust haben, ihre Zeit mit warten auf den Rechner zu verbringen, und die resultierende Dateigröße bei wahllos herausgegriffenen Blockbustern wie "Blade Runner", "Hunger Games", "Inifinity War" bei 2,18 GB, 3,3 GB 4,4 GB liegt und genießen die visuelle Qualität auf ihrem sehr nahe an 6500K, 2,4g kalibriertem TV.

Es gibt andere user, die legen mehr Wert darauf, wenn sie auf ihr NAS schauen, dass diese Blockbuster ein paar MB oder eventuelle 1 GB weniger Speicherplatz belegen und wenden dafür gerne rund 10 mal so viel Zeit pro Kodierungslauf auf.

Im übrigen:

Zeig mir bitte erst mal deine Erfahrung in der Programmierung von Videocodes bevor du anfängst, mir zu unterstellen ich wüsste nicht warum diese entwickelt wurden. Ich jedenfalls habe mich schon seit rd. 2005 immer wieder mit der Programmierung von diversen Codes beschäftigt und zumindest auch schon mal den einen oder anderen Patch zu open-source-Projekten beigesteuert als auch ein plugin beigesteuert. Alles nicht viel, aber bitte zeig erst mal deine Kompetenz, bevor du sie mir absprichst. Wenn du das nicht kannst....

Ach ja, mit sehr wenig Nachdenken kannst du das auch im Netz durch Suchmaschinen herausfinden und bestätigen. Als Starthilfe dafür für dich: mein Nick hier ist bewusst so gewählt.
 
lisanet schrieb:
Okay, dann eben unsachlich weiter, wenn du mit dieser Empfehlung anfängst und mir Unwissenheit über die Grüdne der Entwicklung von Videocodecs unterschiebste, wobie ich dir unterstelle, dass du "unkomprimiertes Video" meintest. Das kann ich auch:
Zum Vergrößern anklicken....
Wenn ich falsch liege, wäre es net, wenn du mich über den Existenzgrund von Videocodecs aufklären könntest.

https://de.m.wikipedia.org/wiki/Videocodec

Frage: Wo habe ich dir deine Kompetenz abgesprochen? Nur mal so nebenbei: Nur weil ich einen Motor konstruieren kann, muss ich noch lange nicht wissen, wie ich in der Formel 1 auf die ersten Plätze komme. Deshalb ist die Konstruktion des Motors trotzdem eine Leistung.
 
Tzunami schrieb:
Wenn ich falsch liege, wäre es net, wenn du mich über den Existenzgrund von Videocodecs aufklären könntest.

Frage: Wo habe ich dir deine Kompetenz abgesprochen?
Zum Vergrößern anklicken....

.. tu jetzt nicht so unschuldig, sondern lies dein eigenes Posting.

Und bevor ich mit dir weiter diskutiere, zeig erst mal, was du von der Materie verstehst außer der dahingeworfenen Behauptung, dass Software-Encoding bessere Qualität liefern würde (Qualität, nicht Größe/Qualität) und außer der Behauptung, dass die weiter oben angeführten Begriffe was mit visueller Qualität zu tun hätten.
 
lisanet schrieb:
.. tu jetzt nicht so unschuldig, sondern lies dein eigenes Posting.

Und bevor ich mit dir weiter diskutiere, zeig erst mal, was du von der Materie verstehst außer der dahingeworfenen Behauptung, dass Software-Encoding bessere Qualität liefern würde (Qualität, nicht Größe/Qualität) und außer der Behauptung, dass die weiter oben angeführten Begriffe was mit visueller Qualität zu tun hätten.
Zum Vergrößern anklicken....

Gehen dir die Argumente aus, das eine Diskussion nun von meinen Programierkentnissen abhängig sein soll?

Wie wäre es mit einer Ausbildung die Funktionsweise von Codecs enthielt und über 30 Jahren arbeiten mit besagten Codecs? Ich bin übrigens einer der Typen, der Filme auf DVDs und BDs bei akzeptabler Qualität gequetscht hat (privat und beruflich).

Reichen 30 Jahre täglich 10-12 Stunden kodieren als Kompetenz?
 
Zitieren
  • Gefällt mir
  • Love
Reaktionen: Stefan_B und FelixMacintosh
Tzunami schrieb:
Gehen dir die Argumente aus, das eine Diskussion nun von meinen Programierkentnissen abhängig sein soll?

Wie wäre es mit einer Ausbildung die Funktionsweise von Codecs enthielt und über 30 Jahren arbeiten mit besagten Codecs. Ich bin übrigens einer der Typen, der Filme auf DVDs und BDs bei akzeptabler Qualität quetschen musste.
Zum Vergrößern anklicken....

dir sind die Argumetne erst mal ausgegeangen.

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


Tzunami schrieb:
Referenz-Frames
B-Frames
Motion Estimation Methode
Subpixle ME
ME Range
Adaptive Quantisierung
Zum Vergrößern anklicken....

mit der von mir angeführten "visuellen Qualität" zu tun haben soll. Es kann natürlich sein, dass du einfach des Widersprechens wegen damit angefangen hast, weg von den Inhalten meines posting zu gehen.

Insoweit also, du fängst mit unsachlicher Argumentation an und ich mach nun weiter. So ist es. Da ich nicht erkennen kann, dass du weder mit der Materie, noch mit dem Thema "visuelle Qualität" mit hälst und mir zudem Unkenntnis über die Gründe der Entwicklung von Codecs unterstellst.... bleib bei deinem Glaubensgrundsatz, dass Software-Encoding besser sei. Mehr Unterhaltung ist mit dir nicht drin.

Bye.
 
Du weist ja,
lisanet schrieb:
dir sind die argumetne erst mal ausgegeangen.-

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




mit der von mir angeführten "visuellen Qualität" zu tun haben soll. Es kann natürlich sein, dass du einfach des Widersprechens wegen damit angefangen hast, weg von den Inhalten meines posting zu gehen.

Insoweit also, du fängst mit unsachlicher Argumentation an und ich mach nun weiter. So ist es. Da ich nicht erkennen kann, dass du weder mit der Materie, noch mit dem Thema "visuelle Qualität" mit hälst und mir zudem Unkenntnis über die Gründe der Entwicklung von Codecs unterstellst.... bleib bei deinem Galubensgrundsatz, dass Software-Encoding besser sei. Mehr Unterhaltung ist mit dir nicht drin.

Bye.
Zum Vergrößern anklicken....

Ich habe bei der Aufzählung eindeutig von Funktionen geredet. Aber interpretiere nur etwas herein, wo nix zu interpretieren ist.

Entweder lässt du diesen Satz vorsätzlich weg oder er ist wegen einer Hornhautkrümmung abhanden gekommen:
Ich rede nicht von "constant quality", sondern von Funktionen wie:

Referenz-Frames
B-Frames
Motion Estimation Methode
Subpixle ME
ME Range
Adaptive Quantisierung
usw.
Zum Vergrößern anklicken....

Wie war das? Wer aufgibt, verliert?
 
Zuletzt bearbeitet:
Zurück
Oben Unten