*offizielles deutsches flaskmpeg & dvdtoogm board* | Druckvorschau: => man x264 <= (Hilfe zum x264 CLI)

Geschrieben von Selur am 10.12.2005 um 20:51:

=> man x264 <= (Hilfe zum x264 CLI)

Da ich schon von einigen Leuten gefragt wurde ob ich nicht etwas wie ein Wissenswertes rund um x264 auch für das CommandLineInterface von x264 schreiben könnte habe ich mich mal drangesetzt und einiges niedergeschrieben.

Feedback, insbesondere Fragen, Anregungen und Verbesserungen sind gerne gesehen.

Aktuell ist Version: 0.0.9

ToDo:

- Scenecut-Beschreibung anpassen, siehe http://forum.gleitz.info/showthread.php?p=317141#post317141

- deadzone Beschreibung anpassen, kleinere Werte haben bessere Grainerhaltung zur Folge nicht umgekehrt. Augenzwinkern

Cu Selur

Geschrieben von JoeB am 11.12.2005 um 09:23:

RE: => man x264 <= (Hilfe zum x264 CLI)

Sehr schön - vor allem Deine Empfehlungen sind klasse und sehr gut argumentiert. Bringt ein feature wenig - stellst Du diesem die Verlangsamung des Encodens gegenüber -> so kann jeder selbst entscheiden.

Gut gefällt mir auch, dass Du jedes feature erstmal technisch erklärst und erst dann die Vor- und Nachteile erläuterst und schliesslich bereits oben erwähnte Empfehlung aussprichst.

Bilder würde ich auch weiterhin weglassen - man könnte ja MeGUI einblenden, aber weis schon was kommt großes Grinsen

Geschrieben von Selur am 11.12.2005 um 12:13:

Bilder werden wohl wenn nur zur Erklärung von Features kommen, ansonsten nicht. Bilder bei einem Kommandozeilentool erscheinen mir irgendwie affig. Augenzwinkern

Cu Selur

Geschrieben von akapuma am 18.12.2005 um 11:27:

RE: => man x264 <= (Hilfe zum x264 CLI)

Hallo Selur,

ich habe noch 2 Fragen:

zu -r bzw. -ref, "sollte normalerweise - 6 sein":
Warum schreibst Du hier 6 anstatt 5?

zu -b bzw. -bframes:
Sehe ich es richtig, daß deren Anzahl, entgegen früherer Empfehlungen im VfW-Wissenswertes, von 2-3 auf 3-5 hochgesetzt wurde?

Gruß

akapuma

Geschrieben von Selur am 18.12.2005 um 12:55:

zu b-frames: Nein, hat sich eigentlich nicht groß geändert, für normale Encodes (wie ich im Wissenswertes anmerkte) würde ich immer noch 3 empfehlen, nur für Animes und niedrige Auflösungen würde ich bis 5 hochgehen. smile

zu ref frames: 5 oder 6 tut sich i.d.R. nichts, kannst ruhig auf 6 bleiben, bei sehr niedrigen Auflösungen (z.B für Handy) bringt sogar 16 noch was. Augenzwinkern

Hab wahrscheinlich 6 genommen, da ich in letzter Zeit öfter für niedrige Auflösungen mal etwa encoded hatte. smile

Cu Selur

Geschrieben von akapuma am 30.12.2005 um 23:49:

Hallo,

Aktuell ist Version: 0.0.4
Ziele für die nächste Version:
1. etweilige Fehler&Co beheben Augenzwinkern

Änderungen zu Version 0.0.3:
- etwas zur --bime Option geschrieben

ich poste mal hier, damit dieser Thread für Abonenten als ungelesen markiert wird. Daß es hier was neues gibt, hab ich nämlich erst im engl. doom9-Forum erfahen.

Danke Selur, weiter so. Ohne Dein Manual hätte ich nie von --bime erfahren.

Gruß

akapuma

Geschrieben von Selur am 31.12.2005 um 00:14:

--bime gibt's erst seit heute, also kein Wunder das Du es nicht kanntest Augenzwinkern

siehe: http://mirror01.x264.nl/x264/changelog.txt

Geschrieben von Selur am 11.01.2006 um 06:06:

Okay, ich hatte das Deblocking falsch verstanden:

Zitat:

Deblocking strength is controled by values called alpha & beta. These values are computed for each macroblock according to the quantizer of this macroblock, the quantizer of its neighbour, and the offset you set ( the famous value that range from -6 to +6 ).

Here are the tables for alpha & beta, indexed by 'quantizer + offset' :

code:

1:
2:
3:
4:
5:


alpha : 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 5, 6, 7, 8, 9, 10, 12, 13, 15, 17, 20, 22, 25, 28, 32, 36, 40, 45, 50, 56, 63, 71, 80, 90,101,113,127,144,162,182,203,226, 255, 255
beta : 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 6, 6, 7, 7, 8, 8, 9, 9, 10, 10, 11, 11, 12, 12, 13, 13, 14, 14, 15, 15, 16, 16, 17, 17, 18, 18

The higher these values, the stronger the deblocking. When one of these is null, there's no deblocking on the macroblock.

As you can see, when 'quantizer + offset <= 15', both alpha and beta are null, so no deblocking is applied.

Alpha is used to determine whether the frontier is blocky or if it's actually a detail. It works like a threshold. Beta also works as a threshold, but is used to insure that on both side of the frontier, the picture is homogenous enough ( once again, to separate detail from blockiness ).

Once you've decided whether or not to filter the frontier, alpha is used to decide the strength ( in fact, the maximal allowed modification to a pixel ). beta can slightly modify this strength, is the macroblock is flat enough.

So in the end, foxyshadis' description is a bit too simple. Both offsets decide which blocks, and the first one influences the bluriness the most.

Quelle: http://forum.doom9.org/showthread.php?p=765770#post765770

Mal schauen wie man das am Besten fürs Wissenswertes übersetzt. smile

(Vorschläge sind gerne gesehen.)

Cu Selur

Geschrieben von Selur am 15.01.2006 um 11:29:

Aktuell ist Version: 0.0.5

Änderungen zu Version 0.0.4
- Deblockingbeschreibung gekürzt
- adaptive quantizer Parameter hinzugefügt

Cu Selur

Geschrieben von akapuma am 05.03.2006 um 11:57:

Hallo,

Zitat x264-changelog:
r456: change default direct mode to spatial

Zitat "Wissenswertes":
"und temporal sieht meist, meiner Meinung nach, etwas besser aus"

Was ist davon zu halten? Läßt man den Parameter weg, wie im Wissenswertes empfohlen, hat man jetzt nicht mehr "temporal", sondern "spatial". Sollte man den Parameter jetzt weiterhin weglassen und "spatial" verwenden, oder sollte man --direct temporal verwenden?

Gruß

akapuma

Edit: vielleicht besser "--direct auto"

Gruß

akapuma

Geschrieben von Selur am 05.03.2006 um 11:59:

Persönlich fand ich temporal sah besser aus => würde also --direct temporal verwenden,...
Gibt's den irgendwo ne Begründugn warum gewechselt wurde?

Zitat:

--direct auto
selects direct mode per frame. works best in 2pass (enable in both passes).

COOL, endlich! smile

=> DAS sollte ab jetzt der Defaultwert für einen sein. smile

Geschrieben von akapuma am 05.03.2006 um 12:00:

Siehe mein "Edit" im Beitrag vorher.

Geschrieben von Selur am 05.03.2006 um 12:01:

*gig*

Aktuell ist jetzt Version: 0.0.6

Änderungen zu Version 0.0.5
- automatisch Entscheidung ob Motionvektorendifferenzen der Makroblöcke eines B-Frames spartial oder temporal ermittelt werden ist nun möglich

Anmerkung:

Spatial sieht bei langsamen und temproal bei schnellen Szenen etwas besser aus als das andere. Augenzwinkern

Geschrieben von Selur am 07.08.2006 um 11:04:

Hab "man x264" auf Version 0.0.7 upgedatet.

Änderungen zu Version 0.0.6
- ein paar Typos
- einige Parameter hinzugefügt: sps-id, qpfile, no-dcr-decimate
- bei den Adaptive Quantizer Parametern angemerkt, dass sie nicht im Standard SVN enthalten sind (handelt sich um Patches von Usern)

Cu Selur

Geschrieben von Selur am 24.10.2006 um 15:04:

Aktuell ist Version: 0.0.8

Änderungen zur 0.0.7:
1. Neu Parameter: --version, --direct-8x8, --deadzone-inter, --deadzone-intra
2. Umbennenung von alten Parametern

Cu Selur