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 
