x264 Kompatiblität mit Standalone Playern

  • Das würde ich nicht auf alle Benutzer anwenden wollen...

    Darum ja auch nur "viele"/"99%" und nicht "alle". War jetzt auch nicht speziell auf Dich bezogen - Deine Einstellungen habe ich mir gar nicht angeschaut.

    Das dachte ich auch, als ich letztens den Vorschlag ausprobiert und die b-frames von 16 auf 8 runtergestellt habe ... bringt bei mir kaum Geschwindigkeitsvorteile ... ahhh ... ich höre schon wie das rumoren losgeht ... "jaja da hast du mit Parameter XYZ die sache wieder obselete gemacht".

    Nein ... ich probiere solche Ratschläge aus, überprüfe das Ergebnis und setze den Ratschlag so oder in abgeänderter Form ein ... in meinem Fall kodiere ich jetzt mit 10 b-frames, weil alles über 10 sogut wie nie in der Summary auftritt und manche meiner Testsequenzen sehr wohl die 10er noch mit 2 bis 10% belegen.

    Und wenn man einen Blick in die Presets wirft, wird man sehen, daß selbst --preset veryslow nur maximal 8 bframes (mit --tune animation 10) verwendet. Alle presets von superfast bis slower verwenden sogar nur 3. D.h. die x264-Entwickler sind der Meinung, daß man die Rechenzeit effizienter nutzen kann, als einfach nur die maximale bframe-Anzahl zu erhöhen. Außerdem: nur daß noch höhere bframes-Zahlen zu einem gewissen Prozentsatz genutzt wurden, heißt im Umkehrschluß nicht, daß auch die Kompression deutlich verbessert wurde. Hier sollte man sehr vorsichtig mit Schlußfolgerungen sein.

    Ja und dann reicht (mir) das völlig aus und ich möchte nicht noch überlegen, ob das Video das ich gerade encode jetzt ein bischen "grainy" ist oder vielleicht doch eher einem "anime" nahe kommt oder oder oder ... wenn das Ding dann kodiert ist und das Ergebnis zum kotzen, dann ärgere ich mich über die vergeudete Encodingzeit und den Stromverbrauch.

    Es zwingt einen ja niemand, --tune zu benutzen - es geht auch ohne. Ich sehe auch nicht ganz, wieso man da seine Zeit für schlechte Ergebnisse verschwenden sollte. Das ist ja gerade der Sinn der presets: Zusammenstellungen verschiedener Parameter für unterschiedliche Zeitansprüche, die bei einer gegebenen Zeit in etwa ein Optimum an Kompression herausholen. Man nimmt das preset, dessen Geschwindigkeit man noch tolerieren kann, wählt dann --crf oder --bitrate aus und fertig. Schneller und idiotensicherer geht es nicht mehr. Wer will, stellt halt noch --level/--vbv-XXX und --tune ein - soo übermäßig kompliziert ist das nicht. Wenn man sich anschaut wie viele verschiedene Parameter x264 hat ist das auf jeden Fall schneller und sicherer, als selbst Experimente zu machen. Die Kombinationsmöglichkeiten an Parametern sind quasi unendlich.

    Ich sehe es halt einfach zu oft und LigH hat es ja auch schon angesprochen: wenn man die Leute dann auf ihre etwas seltsamen und komplizierten Einstellungen anspricht, kommen keine schlüssigen Erklärungen. Außerdem fehlen die Tests, die zeigen, daß ihre Einstellungen besser sind, als die presets. Wenn ich hier und da ein bißchen an --bframes, --ref oder --subme drehe, wird die Welt nicht untergehen, aber man sollte sich nicht der Illusion hingeben, daß man nun ein neues Optimum gefunden hätte, solange man gar keine vernünftigen Vergleichstests durchgeführt hat. Mit letzterem meine ich einen Qualitätsvergleich zu den Presets bei gleicher Bitrate und Zeit. Und wenn dann die Leute anfangen an mbtree, psy und was weiß ich noch was rumzudrehen, werden die Erklärungen oft haarsträubend.

  • Und das hat auch nichts mit vertrauen auf Personen zutun. Beim entwicklen von Frameworks/Bibliotheken/Codecs etc. steht man (meist) vor der schwieriegen Entscheidung, grundlegende Neuentwicklungen mit einzubringen oder Kompatilität zu wahren.

    Bei einem Codec wie dem x264 macht es Sinn, Neuerungen schnell zu implementieren und die Weiterentwicklung so voran zu treiben, weil da "nichts dran hängt" ... keiner wird die Verklagen, wenn sein DVD-Player die aktuellen Presets nicht mehr mag und keiner wird rumstänkern, weil das teil halt kostenlos ist.

    Standards sind an Zeiträume gebunden und somit nicht ultimativ gültig ... wenn ich einen Player habe, der Standard 2009 ist, nützt mit ein neuer "Standard" von 2013 recht wenig.

    Der Witz ist ja: x264 hat keine grundlegenden Neuentwicklungen aus dem Ärmel gezaubert. Der absolute Großteil der Änderungen ist encoderintern. Neue "externe" Features, die auch das Decoding betreffen, folgen ebenfalls dem H.264-Standard. Ja, es kann passieren, daß der ein oder andere Player dann ein Problem damit hat, aber spontan wüßte ich nicht, was sich da in den letzten Jahren groß geändert hätte. Mir fällt nicht ein x264-Feature der letzten Jahre ein, was irgendwie auf einer neuartigen Änderung des H.264-Standards beruhen würde. Letzterer ändert sich doch nicht grundlegend mit ständig neuen Features - das würde doch auch alle Hardwareplayer auf dem Markt zu Elektroschrott machen. Die Entwickler halten sich einfach nur an den Standard und das war es - bei der Vielzahl Geräten auf dem Markt ist es unmöglich, sich da grundlegend zu beschränken, zumal es keine gemeinsame Basis gibt, die auf allen Playern läuft. Es gibt z.B. Geräte die nur CABAC und Geräte die nur CAVLC beherrschen - es gibt einfach keinen kleinsten gemeinsamen Nenner. Die x264-Entwickler halten sich daher nur an den H.264- und Blu-Ray-standard.

    Ich habe nie behauptet, das ich der Parameterguru bin oder das meine Liste frei von kollidierenden Setting sind. Ich habe diese Liste damals mit viel ausprobieren und einem 3 Wochen langen Encoding-Marathon (mit zahlreichen Rückschlägen) erstellt, bis ich den zum damaligen Zeitpunkt besten Qualitätsgewinn erreicht habe.

    Ja, aber von welcher Basis bist Du gestartet, zu der bezogen Du einen Qualitätsgewinn hattest? Wie vorhin erwähnt: die 16 bframes, von denen Du vielleicht mal gestartet warst, sind keine Empfehlung der x264-Entwickler.

    Und wenn ich jetzt eine neuere Version nehme und mit den Empfolenen Presets und Tune aus Wiki, diversen Foren und dem ein oder anderen "Spezialisten" aus Youtube anwende, bekomme ich meist größere Dateien und/oder ein vielfaches der bisherigen Encoding-Dauer, ohne das ich beim direkten Vergleich einen nennenswerten Qualitätsgewinn feststellen kann ... warum also sollte ich meine bisherige Vorgehensweise aufgeben? Nur damit ich "Normgerecht" arbeite?

    Hier kann ich Dir nicht folgen. Wenn Dir die Dateigröße mit den --presets zu groß ist, änderst Du --crf/--bitrate und wenn Dir das preset zu langsam ist, änderst Du --preset. Alles andere ist Unsinn.

  • Die technischen Standards wie H.264 schreiben eben nur technische Details vor, z.B. wie Bewegungsvektoren im Bitstrom codiert vorliegen müssen — aber nicht, mit welchem Aufwand die optimale Übereinstimmung zu suchen ist; hier ist der Vorsprung von x264 zu finden: Es bietet eine Vielzahl von Möglichkeiten, dass jeder seinen optimalen Kompromiss zwischen Rechenaufwand und Entropiereduktion finden kann. Dem einen reicht es, wenn relativ schnell schon sehr gute Ergebnisse gefunden werden, der andere glaubt, er müsse viel mehr Zeit investieren, dass es noch ein klein wenig besser als "sehr gut" wird.

  • Und um "Personenkult" geht es nun wirklich nicht.

    Ok ... das kam mir nur spontan in den Sinn, weil ich wiederholt wahrgenommen habe, das bei hier geposteten Parameterlisten, die mehr als 3 oder 4 Einträge haben schnell mal der Satz kommt "die Entwickler wissen schon was sie tun".

    Solange du dir (und vielleicht auch anderen) genau erklären kannst, warum dieser Parameter jenen Wert hat, wird er auch seine Berechtigung für deine Anwendung haben. Nur bezweifle ich, dass außerhalb des Kreises derer, die an der Entwicklung mitarbeiten und dazu auch die Theorien verstehen, die den implementierten Algorithmen zugrunde liegen, noch viele Anwender ein derartiges Verständnis haben.

    Naja ... manche kann ich erklären und verteidigen, von vielen hab ich nur eine Ahnung und bei denen hab ich diverse Tipps ausprobiert und die Wechselwirkungen an meinem "Referenzmaterial" verglichen. Quasi ein Brute-Force-Attack ;)

    Aber wenn ich nicht probiere, kann ichs nicht lernen.

    Und wenn man einen Blick in die Presets wirft, wird man sehen, daß selbst --preset veryslow nur maximal 8 bframes (mit --tune animation 10) verwendet. Alle presets von superfast bis slower verwenden sogar nur 3. D.h. die x264-Entwickler sind der Meinung, daß man die Rechenzeit effizienter nutzen kann, als einfach nur die maximale bframe-Anzahl zu erhöhen. Außerdem: nur daß noch höhere bframes-Zahlen zu einem gewissen Prozentsatz genutzt wurden, heißt im Umkehrschluß nicht, daß auch die Kompression deutlich verbessert wurde. Hier sollte man sehr vorsichtig mit Schlußfolgerungen sein.

    Das geht bei mir eigentlich immer nach demselben Schema ... ich gewichte die folgenden Kriterien:

    1. beinflusst es die Qualität
    2. beinflusst es die Kompatiblität
    3. beinflusst es die Größe
    4. beinflusst es die Encodingdauer

    Die Entscheidungsfindung für einen Parameter (oder Parameterwert) läuft dann streng hierarchich ab:

    a) beinflusst es die Qualität negativ, toleriere ich das nur unter der Bedingung, das der Verlust extrem minimal und der Gewinn an Größe hoch ist
    b) verringert es die Kompatiblität, toleriere ich das Ausschließlich, wenn Größe und Encodingdauer massiv davon profitieren
    c) beinflusst es die Größe negativ, toleriere ich das nur unter der Bedindung, das das Wachstum minimal und der Gewinn an Geschwindigkeit sehr hoch ist

    Um auf das Beispiel mit den b-frames zurückzukommen:

    a) es beinflusst nicht die Qualität -> weiter
    b) es verringert die Kompatiblität mit meinen Testgeräten nicht -> weiter
    c) bis zu 10 Frames beinflusst es positiv die Größe -> cut von 16 auf 10 -> weiter
    d) der Geschwindigkeitsvorteil von 10 auf 8 ist so maginal, das ich nicht weiter reduzieren werde

    Eigentlich sehr einfach, wenn auch mühselig.

    Achso ... mal so als vergleich ... mit der Parameterliste habe ich Zeiten zwischen den Presets medium und slow ... veryslow find ich übrigens zum weglaufen :eek:

    Das ist ja gerade der Sinn der presets: Zusammenstellungen verschiedener Parameter für unterschiedliche Zeitansprüche, die bei einer gegebenen Zeit in etwa ein Optimum an Kompression herausholen. Man nimmt das preset, dessen Geschwindigkeit man noch tolerieren kann, wählt dann --crf oder --bitrate aus und fertig. Schneller und idiotensicherer geht es nicht mehr. Wer will, stellt halt noch --level/--vbv-XXX und --tune ein - soo übermäßig kompliziert ist das nicht.

    Siehst du, das ist überhaupt nicht mein Schwerpunkt ... die Encdingdauer spielt bei mir nur eine untergeordnete Rolle ... es gab Zeiten, da hab ich ein einziges Video 2 Wochen lang gerendert.

    Wenn man sich anschaut wie viele verschiedene Parameter x264 hat ist das auf jeden Fall schneller und sicherer, als selbst Experimente zu machen.

    Oder bequemer? :zunge:

    Die Kombinationsmöglichkeiten an Parametern sind quasi unendlich.

    Naja ... so unendlich sind die nun auch wieder nicht ... viele schließen sich ja größtenteils gegenseitig aus ... und viele sind ja auch nur "Detailparameter" von größeren "Strategien".

    Ich sehe es halt einfach zu oft und LigH hat es ja auch schon angesprochen: wenn man die Leute dann auf ihre etwas seltsamen und komplizierten Einstellungen anspricht, kommen keine schlüssigen Erklärungen. Außerdem fehlen die Tests, die zeigen, daß ihre Einstellungen besser sind, als die presets. Wenn ich hier und da ein bißchen an --bframes, --ref oder --subme drehe, wird die Welt nicht untergehen, aber man sollte sich nicht der Illusion hingeben, daß man nun ein neues Optimum gefunden hätte, solange man gar keine vernünftigen Vergleichstests durchgeführt hat. Mit letzterem meine ich einen Qualitätsvergleich zu den Presets bei gleicher Bitrate und Zeit.

    Aber nur weil ich heute nicht mehr auf dem Schirm habe, was ich vor 4 Jahren ausgetüftelt habe, heißt das doch nicht zwangsläufig, das ich das damals "übers Knie gebrochen" habe, oder?

    Ich sehe das eher pragmatisch ... ich habe damals eine gute Kombination an Parametern gefunden, die meine Kritieren da oben "vollends befriedigten".

    Jetzt, 4 Jahre später nehme ich eine neue Version des x264, füttere sie mit Presets und Tunes und das Ergebnis ist qualitätiv und quantitativ identisch. Aber die Encodingdauer erhöht sich bis zum 2-fachen.

    Die erste Reaktion war "so'n Käse" ... die zweite "mal gucken, was eine "für die neue x264-Version übersetzte Parameterliste von damals bringt" ... das Ergebnis: Die Qualität ist identisch, die Größe halbiert sich und die Encodingdauer sinkt leicht, weil jetzt alle 8 Kerne nahezu komplett ausgelastet werden.

    Warum sollte ich das jetzt wegwerfen, nur um auf biegen und brechen Presets und Tunes verwenden zu können?

    ... aber von welcher Basis bist Du gestartet, zu der bezogen Du einen Qualitätsgewinn hattest?

    Naja ... ich orientiere mich immer am Ausgangsmaterial. Beim encoden entscheide ich dann, wie "wichtig" mir das Video ist und ändere dann lediglich den einzigen Parameter, der das Verhältnis zwischen Qualität und Größe steuert.

    Und das nach folgenden Kriterien:

    a) Sebstgefimltes, Raritäten und stark verrauschtes/gefiltertes Material -> "optisch lossless" -> CRF14
    b) Gute captures oder digitales Material von "schlechter" Qualität -> "hohe quantitisierung" -> CRF16
    c) alles andere -> "standard" -> CRF18

    Dabei verschwende ich möglicherweise etwas Diskspace, aber da kräht frei nach Morgan eh keiner mehr nach :)

    Wie vorhin erwähnt: die 16 bframes, von denen Du vielleicht mal gestartet warst, sind keine Empfehlung der x264-Entwickler.

    Weil es die Encodingzeit verlängert? Weil es den ein oder anderen Player überfordert?

    Den minimalen Zeitverlust opfere ich und 'nen meckernden Player hatte ich damals bei 16 b-frames nicht gehabt ... who cares :cool:

    Die technischen Standards wie H.264 schreiben eben nur technische Details vor, z.B. wie Bewegungsvektoren im Bitstrom codiert vorliegen müssen — aber nicht, mit welchem Aufwand die optimale Übereinstimmung zu suchen ist; hier ist der Vorsprung von x264 zu finden: Es bietet eine Vielzahl von Möglichkeiten, dass jeder seinen optimalen Kompromiss zwischen Rechenaufwand und Entropiereduktion finden kann.

    So siehts aus ... und die Entwickler haben die "Stellschrauben der Maschine aus dem Gehäuse geführt" damit jedermann, wenn es möchte, von den (vorgeschlagenen) Presets abweichen und sich, frei nach ganz persönlichem empfinden, das für ihn optimale Verhältnis zwischen Qualität, Größe und Rechenleistung zusammenschnüren kann.

    Dem einen reicht es, wenn relativ schnell schon sehr gute Ergebnisse gefunden werden, der andere glaubt, er müsse viel mehr Zeit investieren, dass es noch ein klein wenig besser als "sehr gut" wird.

    Das ist die für mich entscheidende Aussage ... wir sind ja hier nicht in einer Diktatur, wo uns die Obrigkeit sagt, was wir zutun und zu lassen haben ... reicht schon, wenn das der Chef auf der Arbeit gegen Bezahlung machen darf :D

  • Alles andere ist Unsinn.


    Unterschreib.

    "die Entwickler wissen schon was sie tun".


    Zwangsläufig.

    Eigentlich sehr einfach, wenn auch mühselig.


    Und vor allem komplett überflüssig, da die Qualität ja immer an erster Stelle steht und du mit deinem Gefummel keinen signifikanten Unterschied zu den Presets feststellen wirst.


    MultiMakeMKV: MakeMKV Batchverarbeitung (Win)
    MultiShrink
    : DVD Shrink Batchverarbeitung
    Offizieller Übersetzer von DVD Shrink deutsch

  • Dass deine Testgeräte mit bis zu 10 aufeinanderfolgenden B-Frames keine Probleme haben, mag vielleicht glücklicherweise daran liegen, dass x264 praktisch fast nie diesen Spielraum ausschöpft. Aber wenn es einmal passiert, dann erst, nachdem du dich schon jahrelang in Sicherheit gewogen hattest... ;) ...oder wenn du dir dann irgendwann mal ein anderes Gerät kaufst.

    Und das mit dem Qualitätseinfluss ... ist ohnehin sehr subjektiv. Manche mögen es scharf, schärfer, Gibbssches Ringing.

  • Leider werden hier ein paar Dinge übersehen.

    1. --crf garantiert keine konstante Qualität bei verschiedenen Einstellungen oder x264-Versionen
    2. es wird nicht beachtet, daß die Rechenzeit trotzdem noch effizienter in andere Kombinationen gesteckt werden kann

    Für vernünftige Tests muß man zwei Einstellungen bei gleicher Bitrate vergleichen.

    Vor allem das bframes-Beispiel: was sollen A und C bedeuten? Es beeinflußt nicht die "Qualität", aber die "Größe"? Üblicherweise meint man damit dasselbe - "weniger Größe bei gleicher Qualität" bedeutet im Umkehrschluß auch "gleiche Größe bei mehr Qualität", da man frei an --crf und --bitrate drehen kann.

    Achso ... mal so als vergleich ... mit der Parameterliste habe ich Zeiten zwischen den Presets medium und slow ... veryslow find ich übrigens zum weglaufen :eek:

    Siehst du, das ist überhaupt nicht mein Schwerpunkt ... die Encdingdauer spielt bei mir nur eine untergeordnete Rolle ... es gab Zeiten, da hab ich ein einziges Video 2 Wochen lang gerendert.

    Den Widerspruch brauch ich nicht weiter ausführen, oder?

    Oder bequemer? :zunge:

    Ja, es ist bequemer. Spricht ja auch nichts dagegen.

    Jetzt, 4 Jahre später nehme ich eine neue Version des x264, füttere sie mit Presets und Tunes und das Ergebnis ist qualitätiv und quantitativ identisch. Aber die Encodingdauer erhöht sich bis zum 2-fachen.

    Aber es gibt doch Presets in allen Geschwindigkeitsvarianten. Wenn Dir das eine zu langsam ist, nimm halt ein schnelleres! :confused:


    ================


    So, bevor wir uns hier noch totschreiben, ein kleiner, kurzer Vergleich, der zeigen soll, worauf ich hinaus will.

    Quelle:
    http://www.hd-trailers.net/movie/the-wolverine/
    Trailer von Apple, gekürzt auf 1000 Frames ( trim(150, 1149) )

    Zwei Encodes mit 2pass --bitrate 1500:
    A. x264s Standardeinstellungen (entspricht --preset medium, keinerlei --tune oder so etwas) http://www.file-upload.net/download-7451248/standard.mkv.html
    B. Deine Einstellungen aus Beitrag #3 http://www.file-upload.net/download-7451247/gen.mkv.html
    C. wie A nur mit --deblock -3:-3 http://www.file-upload.net/download-74516…db-3-3.mkv.html

    Hier die Bilder, jeweils zuerst die Quelle, dann A, dann B

    Frame 25, man beachte die ganzen Blöcke in Sample B, z.B. in der "0" der "20" oder im Himmel. Außerdem die Kante des Podests.
    http://www.abload.de/img/25_srcvzutz.png
    http://www.abload.de/img/25_stdrnu04.png
    http://www.abload.de/img/25_genklun9.png
    http://www.abload.de/img/25_-38lpsm.png

    Frame 354, in Sample B wieder deutlich mehr Blöcke z.B. an der Unterseite der Flugzeugturbine, zudem teils zackige, ausgefranste Kanten an der Kleidung
    http://www.abload.de/img/354_srcrcuxd.png
    http://www.abload.de/img/354_std81uvo.png
    http://www.abload.de/img/354_genkmuwg.png
    http://www.abload.de/img/354_-3weo9v.png

    Frame 556, man beachte das extreme Aliasing/Blocking bei Sample B auf der rechten Seite des Hintergrunds.
    http://www.abload.de/img/556_srckgupo.png
    http://www.abload.de/img/556_std5eur4.png
    http://www.abload.de/img/556_gen2eunv.png
    http://www.abload.de/img/556_-32vpmx.png

    Frame 783, hier wieder starke Blöcke in Sample B, außerdem ist die Wand links stärker verschwommen
    http://www.abload.de/img/783_src4uu5o.png
    http://www.abload.de/img/783_stdyjus5.png
    http://www.abload.de/img/783_genrkuwd.png
    http://www.abload.de/img/783_-3urpjr.png

    Hier schlagen die absoluten Standardeinstellungen von x264 die mit viel Arbeit selbsterstellten Einstellungen. Und das sogar nicht nur bei der Qualität, sondern auch mit einem kleinen Vorsprung in Sachen Geschwindigkeit. Die x264-Standardeinstellungen arbeiten hier mit 3 bframes also effizienter, als Deine Einstellungen mit 10 bframes.

    Und das ist der Grund, warum man beim Vergleichen von Einstellungen bzw. Abweichen von den Presets sehr sorgfältig und methodisch korrekt vorgehen muß.

    3 Mal editiert, zuletzt von sneaker2 (10. April 2013 um 17:31)

  • Frame 25, man beachte die ganzen Blöcke ...
    Frame 354, in Sample B wieder deutlich mehr Blöcke ...
    Frame 556, man beachte das extreme Aliasing/Blocking ...
    Frame 783, hier wieder starke Blöcke in Sample B ...

    Überrascht mich nicht so wirklich:

    --deblock -3:-3

    Das Inloop-Deblocking erheblich zu reduzieren kann nur in Ausnahmefällen nützlich sein.

    Wer mit dem Deblocking so weit runtergeht, der muss Bitrate im Überfluss haben. So etwas tut sonst nur das Tuning "grain", gerade um den Film-Gries zu erhalten (wie diesen absichtlichen Stilmittel-Gries bei "300"); dann muss man aber auch erwarten, dass die Qualität bei knapper Bitrate verloren geht, weil der Encoder dann ja kaum noch Redundanzen (Ähnlichkeiten) finden kann, durch die er ein gutes Qualitäts-Bitrate-Verhältnis schaffen könnte.

  • Ja, das mit dem Deblocking ist mir auch aufgefallen, aber selbst ein "--deblock -3:-3" bei den Standardeinstellungen scheint es nicht ganz rauszureißen. Habe mal oben entsprechende Screenshots nachgetragen.

    Der Test ist auch nicht der Weisheit letzter Schluß - ist halt niedrige Bitrate und miserable Quelle, aber um meinen Punkt zu verdeutlichen, reicht es. Seine Geräte haben ja evtl. auch etwas andere Kompatibilitätsansprüche, die die Standardeinstellungen ausschließen.

    Einmal editiert, zuletzt von sneaker2 (10. April 2013 um 17:38)

  • Zitat

    Der Test ist auch nicht der Weisheit letzter Schluß


    definitiv nicht :) --no-psy, --deblock -3:-3, --deadzone-inter 2, --deadzone-intra 4 schreit ja gerade zu danach, dass eine für die Bildgröße recht große Datenrate verwendet wird,....
    Dein Test zeigt eigentlich nur, dass
    a. die Standardeinstellung eigentlich immer brauchbare Ergebnisse liefert
    b. Einstellungen die für hohe im Kontext gesehen Datenraten gedacht, bei extrem niedrigen Datenraten versagen,...
    (erinnert irgendwie an die Leute die sich beschwert haben, wenn sie bei Xvid eine für extrem hohe Datenraten (niedrige Quantizer) gedachte Custom Matrix bei normalen Datenraten verwenden und sich beschweren, dass das Ergebnis nicht gut ist)

    Cu Selur

  • b. Einstellungen die für hohe im Kontext gesehen Datenraten gedacht, bei extrem niedrigen Datenraten versagen,...

    Nur daß in der Regel der Nachweis ausbleibt, daß sie bei hohen Datenraten wirklich besser sind. Hier werden manchmal falsche Rückschlüsse im Sinne von "was bei niedrigen Raten gut ist, muß für hohe Raten schlecht sein" gezogen.

  • b. Einstellungen die für hohe im Kontext gesehen Datenraten gedacht, bei extrem niedrigen Datenraten versagen,...

    Danke!

    Meine erste Reaktion auf die Testbedingungen war nämlich "Boah wie unfähr ... kodiert der mit 1500" ... ich kodiere mit CRF18 und einfach zu behaupten:

    Zitat

    1. --crf garantiert keine konstante Qualität bei verschiedenen Einstellungen oder x264-Versionen

    ist polemisch, wenn man die Randbedingungen außer Acht läßt oder "mal eben seine eigenen bzw. Standard-Parameter verwendet".

    Das hat mich spontan dazu genötigt das File runter zu laden um das selbst nochmal zu encoden ... kann ich mir das jetzt sparen?

    Wie ich bereits in meinem letzten Posting angemerkt habe, spielt die Dateigröße an sich für mich die untergeordnete Rolle.

    Mir ist da auch gerade wieder eingefallen, warum ich die deblock Geschichten so weit runtergeschraubt habe. Auf Budget-HD-Fernsehern und/oder in Kombination mit billigen Playern (nein, ich weiß nicht mehr genau welche Kombination damals zutraf), greifen die Postfilter nicht so wirklich befriedigend oder fehlen komplett. Und da ich nicht weiß, welchen TV und/oder Player ich später einsetzen werde, habe ich Bitrate gegen Kompatiblität getauscht. Ich erinnere hierzu an den MS-MPG4x und den dazugehörigen DirectShow-Postfilter, der nur bei bestimmten Auflösungen funktionierte.

    Mein erster Ansatz bestand übrigens darin, das ich maximale Qualit ohne eine Abhängigkeit vom Player haben wollte und die Dateigrößen ruhig gleich groß oder etwas größer, als die DivX alternativen sein sollten.

  • Dass deine Testgeräte mit bis zu 10 aufeinanderfolgenden B-Frames keine Probleme haben, mag vielleicht glücklicherweise daran liegen, dass x264 praktisch fast nie diesen Spielraum ausschöpft. Aber wenn es einmal passiert, dann erst, nachdem du dich schon jahrelang in Sicherheit gewogen hattest... ;) ...oder wenn du dir dann irgendwann mal ein anderes Gerät kaufst.

    Grübel ... hast recht ... muss ich mal nochmal in mich gehen.

    Und das mit dem Qualitätseinfluss ... ist ohnehin sehr subjektiv. Manche mögen es scharf, schärfer, Gibbssches Ringing.

    So siehts aus und deswegen habe ich (wenn auch erst seit ein paar Jahren) auch keine Vorurteile mehr gegen leuz, denen das eine oder das andere eher liegt.

    Ist eh schon lustig, wie einfach die meisten mit billigen, psychovisuellen Tricks dazu gebracht werden, den einen Fernseher besser zu empfinden, als den anderen ... letzte Woche erst hat mein Schwager gemeint, sein alter Rückpro habe ein viel viel schlechteres Bild, als der neue Flachbildschirm von seinem Sohnemann.
    Als ich ihn dann gefragt habe, woran er das fest macht, hat er gemeint, das Bild auf dem (billig) LCD wäre viel schärfer, wenn er Fußball guckt.
    Dann haben wir die Fernseher nebeneinander gestellt und ich habe ihm gesagt, er solle mal in die Zuschauerränge gucken. Die Reaktion war "was ist das denn ... das müsse wohl am Scart-Kabel liegen".

    Dann hab ich ihm erklären müssen, das es einen Unterschied macht, ob ich einen (damals) sehr teuren Toshiba-Rückpro mit adaptiver Rauschunterdrückung oder einem billigen LCD mit einem SD-Sat-Receiver füttere und der einzige "Schärfeunterschied" den er wahrnimmt in diesem Fall der konstruktionsbedingte, höhere Kontrastwert ist.

    Wenn er jetzt Fußball guckt, überlegt er jedesmal, ob er nicht in einen teureren TV und evtl. in einen HD-Receiver investiert.

    Schon witzig ...

  • So! Ich habs jetzt mal mit MEINEN Parametern kodiert ... NULL (in Worten: KEINE) Artefakte ... nada ... nirgendwo ... und nein, ich will die Frames nicht hochladen, weil du entweder ein anderes Video als das "Apple 1080p" benutzt hast, oder nichtmal die richtigen Frame-Nummern angegeben hast ... selbst mit deinem Trim() kann ich die Beispiel Frames nicht über die von dir angegebenen Nummern lokalisieren.

    Poste mal die korrekten Rahmenbedingungen und dann können wir die Äpfel mit den Äpfeln und die Birnen auch mit den Birnen vergleichen.

    Fürs Protokoll:

    Übrigens ... mich würde mal brennend interessieren, wie DEINE tollen Standardparameter bei 1500 den Regen encodet haben [Blockierte Grafik: http://www.smilies.4-user.de/include/Grosse/smilie-gross_290.gif]

  • Uahhh ...

    Resumê:

    Zeit: +5sek ... bei einem 111sek Clip ... auf 90min Film hochgerechnet nicht mal 4min mehr ... zu vernachlässigen
    Endgröße: beindruckend klein

    Qualität:

    a) das ist kein Regen
    b) das sind keine Wolken
    c) die Dame hat nicht solche Flecken im Gesicht
    d) die Übergänge sind ekelhaft (sieht aus wie interlaced)
    e) blurring bei dem Typ auf dem komischen Bett
    f) unscharfe closeups, wenn sich das Objekt im Focus bewegt

    alles in allem nicht schlecht für ein SD-Video ... aber warum kodierst du dann 1080p?

    Mach du ruhig deinen Standard ... ich bleib bei meinem.

    Gruß
    Thom

    Einmal editiert, zuletzt von TheGenesis (10. April 2013 um 23:24)

  • Dein finaler Rückschluss/Behauptung/Unterstellung ist doch schon wieder totaler Quark. Du hast also befunden, dass "Deine" Settings guten Regen etc. produzieren ... bei ~5000kbps. Und dass der vorgegebene Preset keinen guten Regen etc. produziert ... bei 1500kbps.

    Hast Du es wirklich nicht verstanden? Oder tust Du nur so?

    sneaker hat Vergleiche bei gleicher Bitrate gegenübergestellt. (Zur Erinnerung - mit dem Ergebnis, dass der vorgegebene Preset die homogenste Bilddarstellung erzielt hat.) Das Niveau der Bitrate war dabei absichtlich sehr niedrig gewählt, um die Unterschiede besser zu verdeutlichen. Klar kann man auch alles mit 30 Mbps encoden, aber dann sind sowieso alle Einstellung ziemlich wurstegal. Wenn Bitrate hoch [genug], dann sieht alles gut aus.

    Schraub' mal bei Deinen Settings die Bitrate auf 1500 runter. Oder nimm den Standard-Preset und schraube ihn auf 5000 hoch. DANN kannste irgendwas vergleichen.

  • Die Quelldatei habe ich gerade noch mal heruntergeladen, sowohl von Apple als auch vom Mirror und mit der auf meiner Festplatte verglichen. Alle identisch, md5: 033933398B91936BA2388F80327A38CA
    Das AviSynth-Skript sieht nur so aus:

    Code
    ffvideosource("wolverine-tlr1_h1080p.mov")
    trim(150, 1149)

    Mir ist da auch gerade wieder eingefallen, warum ich die deblock Geschichten so weit runtergeschraubt habe. Auf Budget-HD-Fernsehern und/oder in Kombination mit billigen Playern (nein, ich weiß nicht mehr genau welche Kombination damals zutraf), greifen die Postfilter nicht so wirklich befriedigend oder fehlen komplett. Und da ich nicht weiß, welchen TV und/oder Player ich später einsetzen werde, habe ich Bitrate gegen Kompatiblität getauscht. Ich erinnere hierzu an den MS-MPG4x und den dazugehörigen DirectShow-Postfilter, der nur bei bestimmten Auflösungen funktionierte.

    Bei H.264 ist das Deblocking kein frei wählbarer Post-Filter sondern "inloop" und absolut zwingend vorgeschrieben.

    2 Mal editiert, zuletzt von sneaker2 (11. April 2013 um 00:31)

  • Wenn ihr so richtig qualitativ hochwertige Videoquellen zum Vergleichen braucht, hätte ich einen Tipp: Der Sintel-Trailer vom "Durian" Blender Open Movie Project.

    Nachteile:

    1) sintel_trailer-1080-png.tar.gz = 939 MB
    2) ImageSource ist quälend langsam; also für erträgliche Vergleiche habe ich mir mit x264 einmal eine AVC-Kopie mit CRF 6 erstellt; he, das ist mir "verlustfrei genug" als Test-Original.

    Der volle Sintel-Kurzfilm ist übrigens sogar in 4K-Auflösung (4096×1744 Pixel) erhältlich. Als PNGs. Ich weiß im Moment gar nicht, wie ich herausfinden soll, wie viele GB das werden...

    Sogar mit 16 bit Komponenten-Farbtiefe (also bei RGB insgesamt 48 bit pro Pixel). — Denk nicht mal dran!!!

  • Zitat

    Oder nimm den Standard-Preset und schraube ihn auf 5000 hoch. DANN kannste irgendwas vergleichen.


    Nur das macht Sinn Settings von TheGenesis auf hohe Datenrate getrimmt sind, zu gukcen was sie bei 1500kBit/s bei 1080p machen ist nicht hilfreich.
    -> Um die Standardeinstellungen mit den Einstellungen von TheGenesis zu vergleichen sollte man das Testmaterial mit 2pass und einer Bitrate von 5000kBit/s mit beiden Settings encoden. :)

  • Ja, dann müßte wahrscheinlich wirklich eine bessere Quelle her für einen Vergleich bei 5000 kbit/s. Aber heute nicht mehr...

    Ich denke aber mal, um meinen Punkt klarzumachen, daß irgendein sinnloses Drehen an Parametern ohne die richtige Methodik dahinter schnell zu Unsinn führt, hat es schon mal gereicht.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!