Du aber hast tausende Fälle (Standalones) geprüft? Irgendwie trau ich den Entwicklern doch ein wenig mehr Ahnung zu.
Nein, natürlich nicht und das habe ich auch nie behauptet ... ich hab ein paar Referenz-Szenen, die "Gift" für die meisten Codecs sind und an denen man sehr schnell sehen kann, ob ein Codec bzw. Einstellung taugt oder nicht.
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.
Für den einzelnen kann das durchaus problemtisch werden (insbesondere, wenn man sich ständig irgendwelche nightlies zieht).
Die Frage, die ich stelle ist, ob sich jeder der Gesetzmäßigkeit von vorgegebenen Parameterlisten unterwerfen muss, nur weil den Entwicklern von x264 damit "gehuldigt" wird?
Nur eben auf die Gefahr hin, dass die dann jahrelang ungepflegt bleiben und einige dieser Parameter dann in neuen x264-Versionen so nicht mehr unterstützt werden ...
Ich sehe das nicht unbedingt als Gefahr ... wenn natürlich jemand daherkommt und einfach wahllos irgendwelche Vorschläge zusammenschmeisst ohne die Resultate zu verifizieren, dann ist das klar schwachfug.
...nicht mehr Standard sind
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.
...eventuell auch noch bessere zusätzliche Funktionen unbeachtet bleiben
Ja, das ist eine "Gefahr", aber es bleibt docht jedem selbst überlassen, ob er "Encoding-Sicherheit" gegen die eventuell versäumte Verbesserungen tauschen möchte.
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.
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?
Das heißt nicht, das ich keine neuen Sachen ausprobieren möchte, weil ich "das ja immer so gemacht" habe ... nein, ich möchte nur nicht auf biegen und brechen irgendwelche "Standards" einhalten und ich finde die harsche Reaktion auf "gelebte Individualität beim parameterisieren seines Codecs" für völlig übertrieben.
Dieses verteufeln empfinde ich eher Innovationshemmend, als das nichteinhalten von Standards ... denn nur so funktioniert Weiterentwicklung und Evolution 
Viele gehen bei der Erstellung eigener Parameterzusammenstellungen einfach falsch vor. Da wird an Parametern gedreht, bis die Geschwindigkeit paßt...
Das würde ich nicht auf alle Benutzer anwenden wollen ...
...Z.B. können 16 b- oder refframes sehr viel Zeit kosten, aber bringen in der Praxis möglicherweise weniger Vorteile...
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.
...bis die Bitrate/Dateigröße stimmt. Diese sollte man nur mit --crf bzw. --bitrate beeinflussen.
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.
Aber nochmal ... ich finde, die leuz, die keine Lust haben sich einzulesen oder eben massiv zu experimentieren/testen, die sollten auch die Presets und Tunes verwenden, aber ihr solltet vielleicht nicht jedesmal mit dem erhobenen "Lehrerfinger" die leuz mit "böse böse" ermahnen, nur weil sie sich, aus welchen Beweggründen auch immer, ein "eigenes Süppchen" kochen wollen.
Gruß
Thom
