x264 Kompatiblität mit Standalone Playern

TheGenesis

Hi leuz,

ich hab mich gerade mal wieder hingesetzt und wollte eine neuere Version (x264 core:130 r2273 b3065e6 vom 16.03.13) testen.

Nachdem ich meine bisherigen Parameter adaptiert, die Qualität mit der alten Version übereinstimmt, die Geschwindigkeit nahezu identisch ist, bin ich total aus den Schuhen gefallen, als ich gesehen habe, das die Datei nur noch halb so groß wird ... WOW!

Aaabberrr ... jetzt kommt der Punkt, warum ich mich bisher vor so einer Umstellung gescheut habe ... beim damaligen Umstieg von MP43 auf x264 hab ich einen Kompatibilitätsmaraton durch die gesamte Verwandschaft gemacht um herauszufinden, ob die von mir gewünschten Einstellungen auch überall abspielbar sind. Getestet hab ich 2009 mit:

a) PS3
b) xBox 360
c) Coolstream HD1
d) weissnichmehr-HD-DVD-Player

dabei ist herausgekommen, das manche von denen ein 8x8dct nicht mögen.
Als Referenz dazu, hab ich die VLC-0.8.6d genommen um die Streams zu testen.

Heute hab ich bemerkt, das dies nur die halbe Wahrheit ist, denn manche von den neuen defaults gab es damals natürlich nicht und so wird das video meines neuen x264 von dem alten VLC nicht mehr abgespielt (zumindest sieht man nur Grau mit Umrissen), obwohl ich 8x8dct deaktiviert habe.

Das Debug-Log sagt folgendes:

Code

ffmpeg warning: abs_diff_pic_num overflow
 (h264@028814A0)
ffmpeg warning: decode_slice_header error
 (h264@028814A0)
ffmpeg warning: illegal short term buffer state detected
 (h264@028814A0)
ffmpeg debug: concealing 6120 DC, 6120 AC, 6120 MV errors
 (h264@028814A0)

Der alte VLC ist mir eigentlich schnurz egal ... worauf ich hinaus will ist schlicht und ergreifend, das ich wissen möchte, welche "NO-Parameter" ich setzten muss, damit das von gängigen Standalone-Playern noch abgespielt wird.

Wenn ich jetzt wieder rumlaufe und den Leuten meine langweiligen Testvideos aufs Auge drücke, dann enterben die mich

Habt ihr da ne "Nogo-Parameter-Liste" oder noch besser ... wer erbarmt sich eines Tests?

Gruß
Thom

LigH

Als "Wohlfühl-Parameter" wäre da sicherlich --bluray-compat zu nennen, der stellt schon mal eine ganze Reihe Parameter auf kompatible Werte. Allerdings beschränken die wiederum auch die Komprimierbarkeit. Zusätzlich kann es sein, dass du noch passende VBV-Werte angeben musst, damit es auch keine Aussetzer wegen Bitrateschwankungen gibt, die das Auslesen von Scheiben an seine Grenzen bringt. Ansonsten solltest du dich aber auf --preset, --tune und --crf # / --pass # --bitrate # beschränken, wenn es nicht triftige Gründe für noch ein paar spezielle Angaben gibt.

TheGenesis

Werd das mit --bluray-compat mal ausprobieren ... mit preset und tune kann ich mich nicht so wirklich anfreunden ... die machen den encoding Vorgang im Vergleich zu meinen Settings elend langsam und Qualitätsverbesserungen kann ich damit leider auch keine erkennen ... ich hab allerdings auch nocht nicht alle Kombinationen ausprobiert.

Ehrlich gesagt möchte ich auch nicht unbedingt für jede art von Quellmaterial die passende Kombination aussuchen müssen.

Ich bin gerade am überlegen, ob ich nicht mit meinen 2 Referenzvideos nochmal eine Runde durch die Gemeinde mache.

Möchtest du mal meine Parameter ausprobieren und mit einer preset/tune Kombination vergleichen?

Ich meine nicht den theoretischen Ansatz â la "müsste besser, könnte schlechter sein", sondern wirkliches encoden mit meiner und deiner Variante und dann das Ergebnis in punkto Qualität, Größe und Encodingdauer vergleichen.

Hier ist meine aktuelle Parameterliste:

Code

x264.exe --crf 18 --no-8x8dct --no-fast-pskip --ref 4 --bframes 10 --b-pyramid normal --weightb --analyse all --subme 7 --trellis 1 --mixed-refs --no-psy --direct temporal --partitions all --me hex --deblock -3:-3 --aq-strength 0.5 --deadzone-inter 2 --deadzone-intra 4 --threads auto --output "outfile.mp4" "infile.xyz"

Gruß
Thom

monarc99

Zitat von TheGenesis

Hier ist meine aktuelle Parameterliste:

Code

x264.exe --crf 18 --no-8x8dct --no-fast-pskip --ref 4 --bframes 10 --b-pyramid normal --weightb --analyse all --subme 7 --trellis 1 --mixed-refs --no-psy --direct temporal --partitions all --me hex --deblock -3:-3 --aq-strength 0.5 --deadzone-inter 2 --deadzone-intra 4 --threads auto --output "outfile.mp4" "infile.xyz"

Ein paar Dinge sind bekannt, woran sich der eine oder andere HW Player stört. Ob eins dieser Probleme aber bei einem der obigen Player auftritt, musst du selbst ausprobieren.

Empfohlene Werte, wenn man eine Datei möchte, die auf vielen HW Playern abspielbar ist:

--ref und --bframes max: 3
--weightp auf 0 - einige Player zeigen Bildfehler. Diese sind aber schwer zu entdecken, weil diese nur sehr selten auftauchen.
--b-pyramid ist ein Wackelkandidat. Gibt einige wenige Player, die damit Probleme haben
--force-cfr: vfr (variable framerate) - der häufigste Grund, warum sich HW Player weigern eine Datei abzuspielen. Die Datei muss nicht wirklich vfr sein. Wenn mediainfo die Datei als vfr einordnet, haben auch viele Player Probleme damit.

mfg
monarc

LigH

--no-psy ist nur sinnvoll, wenn man technische Metriken zur Berechnung von Bildunterschieden verwenden will, für den menschlichen Betrachter dagegen erscheinen die psychovisuellen Tricks oft angenehmer, auch wenn sie objektiv vielleicht das Bild stärker verändern.

--direct temporal ist mehr oder weniger die veraltete Notlösung, heute kann --direct auto empfohlen werden.

Das Inloop-Deblocking erheblich zu reduzieren kann nur in Ausnahmefällen nützlich sein. Im Allgemeinen würde ich heutzutage darauf vertrauen, dass das Zusammenspiel zwischen --preset und --tune gut funktioniert.

Hier noch mal, was --bluray-compat eigentlich macht:

Zitat von Selur

--bluray-compat

aktiviert ein paar 'Blu-ray hacks':
- min-CR + level 4.1 hack
- Special b-pyramid SEI
- B-frames können keine Frames außerhalb ihrer mini-gop referenzieren
- Open-GOP keyframe interval hack

mach den alten '--open-gop' parameter unnötig:
- jetzt: --bluray-compat + --open-gop <> alte version: --open-gop bluray
- jetzt: --open-gop ohne --bluray-compat <> alte version: --open-gop cbrHD

erzwingt:
- aud=1
(-> muss also nicht mehr in Aufruf auftachen wenn '--bluray-compat' verwendet wird)

beschränkt:
- bframes zu: <= 3
- bpyramid zu: strict oder none
- max references zu: <=6
- weightp zu: 1 oder 0
- nalhrd >= vbr

vbv-maxrate, vbv-bufsize, keyint und slices werden durch --bluray-compat nicht geändert/beschränkt und sollten per Hand gesetzt werden um echte Blu-ray-Kompatibilität zu haben.

Alles anzeigen

may24

Wenn's um PS3 konformes Encoding mit x264 geht, dann kannst du gerne dieses hier übernehmen:

Code

"C:\Program Files\x264\x264-r2273.exe" --crf 19 --level 4.1 --b-adapt 2 --bframes 3 --ref 5 --partitions all --direct auto --weightb --me umh --subme 10 --mixed-refs --8x8dct --no-fast-pskip --no-dct-decimate --vbv-bufsize 30000 --vbv-maxrate 38000 --trellis 2 --threads auto --output myvid.h264 myvid.avs

... mehrfach (vom mir) getestet
Bei der PS3 kommt's vor allem auf die Anzahl der (max 3) B-Frames an. Auch sollte man es mit den Referenzen nicht übertreiben.

TheGenesis

Danke euch erstmal für die Tipps und Parameter ... ich werde mich wohl nochmal durch die ganzen Params durchwursteln und die Ergebnisse mit meinen Referenzvideos vergleichen müssen.

Momentan bin ich nämlich mit der Encoderleistung extrem zufrieden, was Qualität, Größe und Ecodingdauer angeht ... aber jetzt ist leider erstmal der Urlaub vorbei

LigH

Die Art und Weise, wie hier immer wieder Nutzer mit mäßig umfangreicher praktischer Erfahrung beeindruckend lange und detaillierte Parameterlisten als das Optimum vorstellen, erinnert mich an eine bestimmte Art von scherzhaften Wortspielen wie in diesem Beispiel:

Zitat

Wenn mehrere Facharbeiter für Speisenzubereitung gemeinsam arbeiten, führt das dazu, dass sie die zubereitete breiartige Masse unbrauchbar machen.

Die Entwickler von x264 dagegen, die wesentlich mehr Verständnis für die Algorithmen und die Arbeitsweise des Encoders haben, haben viel Aufwand in die Entwicklung eines Systems gesteckt, das mit wenigen und intuitiv verständlichen Parametern (Preset, Tune, bald auch Device) sehr gute Ergebnisse für tausende überprüfte Fälle liefert:

Zitat

Viele Köche verderben den Brei.

Wer unbedingt optimale Optionen für spezielle Fälle benötigt, der kann gerne noch "Sterne-Köche" und "Hirse-Brei" dazuschreiben, dann aber gelten die Optionen auch wirklich nur für eben diese speziell diese Art von Videomaterial.

Rattenjäger

Das stimmt, mit 3 B-Frames und 5 ref-Frames ist man gut unterwegs, benutzte ich schon lange und auf der PS3 lief bisher alles.
Sehr gerne von PS3 und Co wird das Level Main 4.1 gesehen.
Ansonsten habe ich die default Einstellungen von MeGui für x264 nicht verändert.

TheGenesis

Die Entwickler von x264 sind auch nur Menschen ... und Menschen sind nicht vollkommen ... ergo auch nicht unbedingt die Presets ... auch glaube ich kaum, das die Entwickler Ihre Presets mit tausenden Fällen prüfen.
Und es ist auch die Freiheit, die man bei den Open-Source-Programmen mit solcher Fülle an Parametern hat, für sich persönlich den optimalen Kompromiss zwischen Qualität, Endgröße, Kompatibilität und Geschwindigkeit zu wählen.
Außerdem scheren sich die x264 Entwickler vermutlich weniger um die Altbestände an Playern und das ist auch gut so, denn sonst würde es die weitere Entwicklung behindern.
Trotzdem geben sie den Usern einen hervorragenden Katalog an Einstellmöglichkeiten an die hand, sodaß, wie bereits gesagt, jeder sich sein "Süppchen" selber kochen kann ... daran finde ich nichts falsches.

Um mein Beispiel nochmal aufzugreifen ... sobald ich von meiner persönlich bevorzugten Parameterliste abweiche, geht die Encodingdauer auf Faktor 2 hoch ... egal welches tollen Presets und Tunes ich verwende ... naja ... vielleicht gibt es ja tatsächlich irgendeine Kombination, die meiner individuellen Gewichtung nahekommt ... aber ich möchte nicht bei jedem Film aufs neue probieren, wenn ich bereits einen (wenn auch sehr statischen) Ansatz habe.

Und hätte ich "einfach mal eine neue Version" benutzt und mich auf die tollen defaults verlassen, hätte ich etliche Videos in meiner Sammlung, die ich z.B. mit vlc 0.8 nicht mehr direkt hätte auf meinem TV gucken können.

Didée

Die x264-Devels machen einen sehr guten Job damit, den definierten Standard umzusetzen /bzw. dessen Möglichkeiten auszuloten.

Wenn da -zig-hunderte von abgespeckten mini-Chips kursieren, oder User auf veralteter Software (VLC 0.8) bestehen, wo die HW oder SW jammert "ich kann aber den Standard nicht so richtig, sondern ich kann nur dies und das, aber bitte nicht jenes oder folgendes", dann .... ist das nicht wirklich das Problem der x264-Devels. Schon allein weil da wiederum -zih-hunderte von Kombinationen enstehen, was der eine oder der andere eben gerade kann oder nicht kann. Deswegen gibt es den Standard. Sogar so richtig schön nach Profilen und Levels unterteilt. Und wer sich nicht an die Spielregeln des Standards halten kann, der muss eben draußen bleiben und darf nicht mitspielen.

Ich will bitteschön H264-HD-Videos auf meinem Hobbykeller-PC mit Windows 3.1 abspielen! Wie, was heißt hier "geht nicht"?! Mann mann mann, was für ein Schei**-Codec das doch ist ...

TheGenesis

Nein, das hat keiner gesagt ... ich habe lediglich versucht zu verteidigen, warum ich und manche (viele?) andere eben nicht mit Presets und Tune arbeiten, sondern fest verdrahtete Parameterlisten = "eigene Profile" verwenden.

Außerdem ist eine "veraltete" Software/Hardware in meinen Augen kein Grund zu sagen: "Och, der x264 mit seinen Presets kann das nicht, muss ich mir halt neue Software/Hardware anschaffen".
Bei Software geht das ja in den meisten Fällen noch, aber bei der Hardware hörts (zumindest bei mir) dann auf. Ich hab keinen Bock Geräte zu ersetzen, die genau das liefern was ich brauche und die mal viel Geld gekostet haben ... da kauf ich mir lieber was anderes oder mach mal Urlaub oder bezahl die nächste Ölrechnung, damits im langen Winter nicht plötzlich kalt wird.

Wie gesagt ... keiner hat behauptet, er "will mit Win3.1 oder sonstichwas" und niemand hat gesagt der Codec sei Sch***e, aber verdammt nochmal was ist so falsch daran, nicht mit dem großen Strom zu schwimmen und die Presets den leuten lassen, die keinen Bock haben Alternativen auszuprobieren ...

und so weiter und so fort ... sollen wir für diese Grundsatzdiskussion nen separaten Thread eröffnen?

Chetwood

Zitat von TheGenesis

Die Entwickler von x264 sind auch nur Menschen ... und Menschen sind nicht vollkommen ... ergo auch nicht unbedingt die Presets ... auch glaube ich kaum, das die Entwickler Ihre Presets mit tausenden Fällen prüfen.

Du aber hast tausende Fälle (Standalones) geprüft? Irgendwie trau ich den Entwicklern doch ein wenig mehr Ahnung zu.

hdst

Vor längerer Zeit hatte ich hier im Forum bereits vermerkt, daß --bluray-compat keine absolute Kompatibilität mit SA-Player bedeutet und auf meinen Panasonic hingewiesen. Werde das mit der neuen x264-Version nochmals prüfen.

Selur

Ein paar Gedanken:

das die Auflösung und Frameraten nur solche sein dürfen, die dem Blu-ray Standard entsprechen setze ich mal als 'klar' voraus. (ansonsten macht --bluray-compat eigentlich kaum Sinn)
zusätzlich zu --bluray-compat müssen noch die VBV Werte gesetzt sein.
einige Hardware Blu-ray Player kommen wohl auch nicht mit 'b-pyramid' klar.
--weigthp 2 macht auch bei manchen Playern Probleme -> --weightp 1 oder --weightp 0 nutzen
wenn man mkv Files für einen Hardware Player erstellt sollte man sich https://trac.bunkus.org/wiki/FAQ%3AImp…lityWithPlayers mal durchlesen
wenn man mp4 Files für Apple Geräte erstellt müssen noch einige Einschränkungen berücksichtigt werden (kein Interlaced, spezielle flags im Container, meist nur stereo audio)
wenn man für Nicht-Blu-ray-Hradware-Player encoded sollte man vorher mal antesten, was für Profile diese unterstützen

Cu Selur

LigH

Zitat von TheGenesis

... ich habe lediglich versucht zu verteidigen, warum ich und manche (viele?) andere eben nicht mit Presets und Tune arbeiten, sondern fest verdrahtete Parameterlisten = "eigene Profile" verwenden.

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, oder bestimmte Werte die Bedeutung ändern, nicht mehr Standard sind, eventuell auch noch bessere zusätzliche Funktionen unbeachtet bleiben (z.B. --direct auto als neuer Standardwert, da im Allgemeinen optimal im Vergleich zu entweder spatial oder temporal).

Presets und Tunings werden bei solchen Neuerungen darauf mit angepasst. Und das auch mit dem nötigen Detailverständnis aller Einzelheiten des H.264-Verfahrens aus technischer Sicht; oder könntest du dir selber z.B. die "deadzone" und ihre Auswirkungen erklären? Sicher kann man experimentieren und gute Werte finden, aber das Verständnis der Zusammenhänge zwischen mehreren Parametern hilft, unsinnige Kombinationen von vorn herein auszuschließen, oder proportionale Änderungen mehrerer Parameter zu einem intuitiv verständlichen Tuning zusammenzufassen.

Zitat von hdst

Vor längerer Zeit hatte ich hier im Forum bereits vermerkt, daß --bluray-compat keine absolute Kompatibilität mit SA-Player bedeutet und auf meinen Panasonic hingewiesen. Werde das mit der neuen x264-Version nochmals prüfen.

Das hatte auch Selur in dem in #5 zitierten Abschnitt erwähnt: Die entsprechenden Hacks kümmern sich vorwiegend um die Beschränkungen des Decoderchips, aber die Beschränkungen des optischen Laufwerkes und der Decodierpuffergröße (VBV) darf man auch nicht übersehen, wenn es wirklich richtig standardkonform werden soll.

sneaker2

Zitat von Selur

[*]--weigthp 2 macht auch bei manchen Playern Probleme -> --weightp 1 oder --weightp 0 nutzen

Ist deshalb ja auch in --bluray-compat drin.

Ansonsten kann ich LigH nur zustimmen. Viele gehen bei der Erstellung eigener Parameterzusammenstellungen einfach falsch vor. Da wird an Parametern gedreht, bis die Geschwindigkeit paßt, aber es wird übersehen, daß man nicht allein von der Geschwindigkeit auf die erreichte Kompression schließen kann. Die Zusammenstellung der Presets ist so ausgelegt, daß man bei einer gegeben Geschwindigkeit in etwa ein Optimum an Kompression rausholt. Z.B. können 16 b- oder refframes sehr viel Zeit kosten, aber bringen in der Praxis möglicherweise weniger Vorteile, als andere Parameter. Man setzt die vorhandene Rechenleistung also ineffizient ein.
Der zweite Fehler ist, an irgendwelchen Parametern zu drehen, bis die Bitrate/Dateigröße stimmt. Diese sollte man nur mit --crf bzw. --bitrate beeinflussen.

Ansonsten stimmt es natürlich: die Presets und Tunings sind nicht immer das Optimum. Allerdings fehlt 99% der Anwender das nötige Verständnis bzw. die nötige Erfahrung, es im Einzelfall besser hinzubekommen.

TheGenesis

Zitat von Chetwood

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?

Zitat von LigH

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.

Zitat von LigH

...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.

Zitat von LigH

...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

Zitat von sneaker2

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 ...

Zitat von sneaker2

...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.

Zitat von sneaker2

...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

Chetwood

Zitat von TheGenesis

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?

Die Frage ist schon völlig falsch gestellt. Aber viel Spaß noch beim Rumprobieren.

LigH

Mir geht es bei "nicht mehr Standard sein" nicht um industrienormierte Player-Standards, nur um Standardwerte für x264-Optionen (was im Hilfetext in [eckigen Klammern] steht).

Es gab schon mal einen Meilenstein in der x264-Entwicklung, als mehrere Optionen mit ihrem Gegenteil ersetzt wurden, damit deren Funktion beim Aufruf ohne viele Parameter lieber aktiviert als deaktiviert sein solle.

Und um "Personenkult" geht es nun wirklich nicht. 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.

Jetzt mitmachen!