Unklarheiten bezüglich neueren x264CLI Optionen

Hallo,

in den news steht öfter was von "10l", z.B. "10l in r473 and stdin". Was heißt das eigentlich?

Gruß

akapuma

"10l" (~ LOL) = "ein so dämlicher Faselfehler, dass man das besser nicht detailliert in der Öffentlichkeit erklärt"

Zitat von nexustheoriginal

r478: * configure: support for 64 bits MIPS.

Was ist ein 64 bits MIPS? (ist bestimmt blöd die Frage, aber ich weis es wirklich nicht )

Hier geht es nicht um die Rechenleistung MIPS, sondern um den 64-bit-Prozessor.

http://de.wikipedia.org/wiki/MIPS-Architektur

@ Selur & Ligh

Danke

Hab dein Post zu spät gesehen.
Siehe hier: http://forum.gleitz.info/showthread.php?t=27792

Zitat

Bringt es etwas das Feature zu nutzen?

Es sollte etwas mehr Details erhalten, verringert aber auch die Kompression. In hohen Bitraten würde ich es einschalten, in niedrigen und bei Cartoon/low-detail Animes aus. Ich habe aber noch keine Tests gemacht um meine Behauptung zu stützen.

Zitat von Selur

Kann wer etwas mehr zu "--no-dct-decimate" sagen als im Changelog steht? Bringt es etwas das Feature zu nutzen?

Zitat von sade

Es sollte etwas mehr Details erhalten, verringert aber auch die Kompression. In hohen Bitraten würde ich es einschalten, in niedrigen und bei Cartoon/low-detail Animes aus. Ich habe aber noch keine Tests gemacht um meine Behauptung zu stützen.

Hat jemand dazu schon Test gemacht? Ein kleiner Testclip mit trellis 1 wurde mit --no-dct-decimate fast 6% größer.

Gruß

akapuma

Das hat Kopernikus besser erklärt als ich zunächst verstanden hatte.

Zitat von LigH

Das hat Kopernikus besser erklärt als ich zunächst verstanden hatte.

Dann zitiere ich mal hieraus, in der Annahme, daß ich hier im richtigen Thread bin:

Zitat von Kopernikus

DCT Decimation verwirft Frequenzkomponenten, die nach der Quantisierung nur sehr kleine Amplituden haben. Das erhöht die Effizienz der nachfolgenden verlustfreien Kompression in einen Bitstream mit RLE und Huffman.

Trellis geht an das selbe Problem etwas professioneller (aber halt auch alangsamer) ran und findet eine nach RD Gesichtspunkten optimale Quantisierung.

Und noch ein Zitat aus Selurs "man":

Zitat

Standardmäßig ist bei B-Frames diese Dezimierung immer deaktiviert und bei Trellis immer an

Wenn Trellis "das selbe Problem etwas professioneller angeht", warum ist die Dezimierung dann bei Trellis immer an? Nach der Erklärung von Kopernikus (so, wie ich sie verstanden habe), müßten sich Trellis und DCT Decimation doch "beißen".

Gruß

akapuma

So sehe ich das auch: "Entweder DCT Decimation oder Trellis RD" würde ich auch so herauslesen.

Hallo,

ich habe mal folgendes probiert:

kein trellis, kein --no-dct-decimate => 4168kB
trellis = 1, mit --no-dct-decimate => 4786kB

Vom Platz her wäre die DCT-Dezimierung ja Trellis weit überlegen (bei meinem kurzen Clip rund 15%). Bringt Trellis qualitativ wirklich so viel? Man könnte es ja auch weglassen und mit einem kleineren --crf-Wert die gleiche Dateigröße erreichen, vielleicht wäre das besser.

x264.exe --crf 25 -I 300 -i 120 -r 6 --mixed-refs --no-fast-pskip -b 4 --b-pyramid --b-rdo --bime -w -f 1,1 -m 7 -A all -8 -- qpstep 8 --aq-strength 0.5 --direct auto --b-bias 30 --thread-input --progress --no-psnr --no-ssim -o "film.mkv" film.AVS

Gruß

akapuma

Edit: hier gefunden:

Zitat

Description: This option when turned on is supposed to improve quality, but at a severe slow down of encoding. The quality improvements are also subjective. Leaving it Off is recommended unless you have a fast computer and using multi-pass encoding. Never turn it on in single pass quantizer mode, as it would lead to unexpected results.
Available Options:
Disabled: Use this for 1-pass encoding
Final MB: Use this for typical 2-pass encoding
Always: Use this for maximum quality (slowest speed)
Command Line: --trellis n
(where 'n' is 0 {disabled}, 1 {Final MB} or 2 {Always})

Alles anzeigen

Das war's dann, oder?

Gruß

akapuma

Edit2: Zitat von hier:

Zitat

it's (trellis) unpredictability in Constant Quantizer mode

unpredictability=unberechenbar

Zitat von LigH

So sehe ich das auch: "Entweder DCT Decimation oder Trellis RD" würde ich auch so herauslesen.

Und nochmal Zitat vom Link hiervor:

Zitat

Note: it is a good idea to turn this (trellis) ON if you decide to uncheck "DCT Decimation."

However, if you decide to use Trellis, you might consider turning this (DCT decimation) off in order to best allow trellis to be the determining factor in what information gets dropped/skipped without interference from other options.

Fazit:
==> kein Trellis bei konstantem Quantizer (und ich denke auch CRF)
==> beim 2-Pass-Verfahren Trellis oder DCT-Dezimierung, also trellis immer in Verbindung mit --no-dct-decimate benutzen

Hallo,

wenn ich DeathTheSheep richtig intepretiere, soll man beim 2-Pass-Verfahren, wenn überhaupt, nur trellis oder die DCT-Dezimierung oder Fast-P-Skip verwenden, also:

-trellis --no-fast-pskip --no-dct-decimate (nur trellis)
--no-dct-decimate (nur fast P-Skip)
--no-fast-pskip (nur DCT-Dezimierung)

Gruß

akapuma

Edit: Vielleicht verstehe ich das auch falsch.

Na, es macht schon Sinn, das so zu sehen: Alle drei Funktionen versuchen, die Größe von P-Frames zu reduzieren - aber jeweils auf eine andere Art der Reduktion, mit einem anderen Ansatz. Wenn man mehrere dieser Techniken kombiniert, dann kann das verständlicherweise zu Nebenwirkungen führen. Wahrscheinlich zum merklichen Verlust von Informationen und nachhaltiger Verschlechterung der Qualität. Das kennen wir ja schon aus der wiederholten Encodierung bereits encodierter Videos.

GUI-Autoren sind also sicher gut beraten, hier eine Auswahl per Combobox oder Radiogruppe anzubieten; vielleicht in etwa "P-Frame-Reduktion: Schnell (Fast P-Skip) | Einfach (DCT Decim.) | Gut (Trellis RD) { Final | Always }".