Unklarheiten bezüglich neueren x264CLI Optionen

[Selur]

"r474: separate --thread-input from --threads"
=> Bedeutet das, die Option separiert den thread der für die Synchronisation der anderen threads zuständig ist von diesen, was auf Multi-Prozessor/-Core System nochmal einen leichten boost geben sollte?

[sade]

"r474: separate --thread-input from --threads"
=> Bedeutet das, die Option separiert den thread der für die Synchronisation der anderen threads zuständig ist von diesen, was auf Multi-Prozessor/-Core System nochmal einen leichten boost geben sollte?

#ifdef HAVE_PTHREAD
if( b_thread_input || param->i_threads > 1 )
{
if( open_file_thread( NULL, &opt->hin, param ) )
{
fprintf( stderr, "threaded input failed\n" );
}
else
{
p_open_infile = open_file_thread;
p_get_frame_total = get_frame_total_thread;
p_read_frame = read_frame_thread;
p_close_infile = close_file_thread;
}
}
#endif

Du bekommst also threaded Input wenn du threads>1 stellst, oder --thread-input verwendest.
Falls du keine Slices verwenden möchtest, kannst du so immernoch davon profitieren.

[Selur]

hmmm,.... ist der Parameter nicht unsinnig, wenn er so abgefragt wird. Meine solange Thread <1 ist sollte thread_input ja nix machen und danach ist er egal, irgendwie merkwürdig.
Hab's mal aus dem Newsbeitrag abgetrennt damit eventuell noch ein paar andere Leute eventuell etwas posten und wir hier einen Thread haben wo immer die neusten Features bequatsched werden können, die noch nicht im 'man x264' oder im 'Wissenswertes rund um x264' auftauchen.

Cu Selur

[Kopernikus]

Wieso? Wenn --threads > 1 oder --threaded input, soll x264 einen speziellen Thread für Prefetching verwenden.

Die Geschwindigkeitsgewinne, die im englischen Forum berichtet wurden, waren teilweise recht groß.

[LigH]

Bestätige - Dateioperationen in einem eigenen Thread sind häufig sehr empfehlenswert, auch für 1-Core-PCs. Nicht umsonst verwenden z.B. VirtualDub* und HeadAC3he dafür eigene Threads.

Die Option "--thread-input" ist somit generell (auch für 1-Core-PCs) nützlich, und für Multi-Core-PCs sollte man dann so viele Rechen-Threads wie Cores verwenden (der Disk-Thread teilt sich da schon rein, der braucht nicht viel Zeit).

[Selur]

Okay, d.h. dann:

1. --thread-input sort dafür, dass ein Datei- und Synchronisationsoperationen etweiliger anderer Threads in einem separaten Thread ausgeführt werden. (Richtig?)
2. Wenn man mehr als einen Thread verwendet braucht man die Option nicht aktivieren, da auf jeden Fall ein spezieller Thread fürs Prefetching verwendet wird. (Richtig?)
3. Bei 1-Core-CPUs sollte die Option auch aktiviert werden, da es auch dort zu Geschwindigkeitsgewinnen durch die Separierung kommen kann. (Richtig?)

Cu Selur

[LigH]

1) Inhaltlich richtig. Rechtschreibung wird noch mal in einem etwaigen separaten Thread behandelt! ;)
2) Ich glaube ja - denn zwischen mehreren Encoding-Threads muss ja ein Synchronisations-Thread "verhandeln", und der kann auch gern den Dateizugriff mit übernehmen, er muss ja die Daten verteilen.
3) Das wollte ich damit ausdrücken.

[Selur]

zu 1.: Danke für die Korrektur. :) (Etwaigen schreib ich irgendwie fast immer falsch, genauso wie ich statt 'falsch' gerne 'flasch' schreibe. :) )

Mal noch gucken was Kopernikus dazu sagt und wenn der dem auch zustimmt werd ich mal ein Update des 'man x264' machen. :)

Cu Selur

[Kopernikus]

1.) Der Input Thread liest die Quelldaten ein, er erledigt auch ggf. die avisynth arbeit (VirtualDub macht das auch, Doom9 hat im Codec Comparison angemerkt, dass das deutliche Gewinne gebracht hat bei (damals noch nicht SMP optimierten) XviD. In die Ausgabedatei schreiben wird vom Hauptprozess gemacht.

2.) Das geht aus dem Stück Code hervor, das Sade gepostet hat, ich denke, dass das auch so im svn steht :)

3.) Weiß ich nicht, hab ich nicht ausprobiert, aber im englischen Forum wurden teilweise kleine Gewinne für Single Core berichtet (aber wie verlässlich das ist weiß man ja nicht).

[Selur]

Hmm,.. wenn es keine Gewinne für Single CPUs bringen sollte ist der Parameter sinnfrei, da er dann ja nur sinnig ist wenn man eh mehrere Threads benutzt in welchem Falle er ja nichts extra macht. (davon ausgegangen Leute die mehrere Cpus/Cores haben auch Threads >1 benutzen)

Cu Selur

Ps.: ich teste das mit dem single Core später mal (momentan nicht zuhause)

[Selur]

Hab hier mal angetestet und da bremst es eher bei SingleCPUs:

1. ohne --thread-input
x264.exe -o "d:\test.mp4" "d:\test.avs" -p 1
=>encoded 3621 frames, 15.95 fps, 1863.25 kb/s

x264.exe -o "d:\test.mp4" "d:\test.avs" -p 2
=>encoded 3621 frames, 16.20 fps, 1863.25 kb/s


2. mit --thread-input
x264.exe -o "d:\test.mp4" "d:\test.avs" -p 1 --thread-input
=>encoded 3621 frames, 15.95 fps, 1863.25 kb/s

x264.exe -o "d:\test.mp4" "d:\test.avs" -p 3 --thread-input
=>encoded 3621 frames, 16.08 fps, 1863.25 kb/s

=> Wäre hilfreich wenn noch ein paar andere Leute das Testen könnten.

Cu Selur

[sade]

Hmm,.. wenn es keine Gewinne für Single CPUs bringen sollte ist der Parameter sinnfrei, da er dann ja nur sinnig ist wenn man eh mehrere Threads benutzt in welchem Falle er ja nichts extra macht. (davon ausgegangen Leute die mehrere Cpus/Cores haben auch Threads >1 benutzen)

Slices (die mit threads>1 gebildet werden) reduzieren die Qualität ein wenig.
Deswegen kann es sinnvoll sein keine Threads zu benutzen auch wenn man mehrere CPUs benutzt. Außerdem hatten (haben?) einige Decoder Probleme mit Slices.

[sade]

Hab hier mal angetestet und da bremst es eher bei SingleCPUs:

1. ohne --thread-input
x264.exe -o "d:\test.mp4" "d:\test.avs" -p 1
=>encoded 3621 frames, 15.95 fps, 1863.25 kb/s

x264.exe -o "d:\test.mp4" "d:\test.avs" -p 2
=>encoded 3621 frames, 16.20 fps, 1863.25 kb/s


2. mit --thread-input
x264.exe -o "d:\test.mp4" "d:\test.avs" -p 1 --thread-input
=>encoded 3621 frames, 15.95 fps, 1863.25 kb/s

x264.exe -o "d:\test.mp4" "d:\test.avs" -p 3 --thread-input
=>encoded 3621 frames, 16.08 fps, 1863.25 kb/s

=> Wäre hilfreich wenn noch ein paar andere Leute das Testen könnten.

Cu Selur
Der Test ist sinnlos wenn du nicht dein avs script postest.
Aber ich verstehe auch nicht was es bei Single Core CPUs bringen soll.

[Kopernikus]

Aber die Qualitätsunterschiede sind sehr gering. Ich glaube nicht, dass irgendjemand durch Hinschauen einen Unterschied zwischen einer sliced und nicht sliced Variante eines Encodes erkennt.

Gerade im englischen Board aufgeschnappt:

Der Prefetch Thread hilft, wenn die CPU nicht der limitierende Faktor ist, also wenn man z.B. unkomprimiertes Quellmaterial verwendet.

[sade]

Aber die Qualitätsunterschiede sind sehr gering. Ich glaube nicht, dass irgendjemand durch Hinschauen einen Unterschied zwischen einer sliced und nicht sliced Variante eines Encodes erkennt.
Ist wahrscheinlich für die selben Leute gedacht, die auch --me esa verwenden.

[Kopernikus]

und 3Pass :)

[Selur]

mein avs file:
LoadPlugin("L:\Programme\DGIndex\DGDecode.dll")
mpeg2source("D:\HDTV\test.d2v")
-----------

Slices (die mit threads>1 gebildet werden) reduzieren die Qualität ein wenig.
Deswegen kann es sinnvoll sein keine Threads zu benutzen auch wenn man mehrere CPUs benutzt. Außerdem hatten (haben?) einige Decoder Probleme mit Slices. d.h. es sollte einen boost geben wenn ich später auf meiner Dual Kiste (Dual Athlon 1800+ MP):
x264.exe -o "d:\test.mp4" "d:\test.avs" -thread1
und
x264.exe -o "d:\test.mp4" "d:\test.avs" -thread1 --thread-input
vergleiche?

-----------
Der Prefetch Thread hilft, wenn die CPU nicht der limitierende Faktor ist, also wenn man z.B. unkomprimiertes Quellmaterial verwendet.
d.h. wenn die Platte mit dem Hinterherschieben nicht mitkommt? => in der normalen DVD/HDTV => xy Umgebung unsinnig?


Cu Selur

[sade]

bei DVD* Auflösung hast du:
704 * 576 * 12/8 = 608256 Bytes (~0.58 MB/Base 1024) pro Frame.
Also bei >10fps könnte es etwas bringen.

*unkomprimiert was sowieso kaum jemand verwendet

[Selur]

Könnte das eventuell mal einer der Captureleute antesten?
(ich teste heute abend mal ob --thread-input beim Encoden mit 1 thread auf einer Dual CPU Maschine etwas ändert)

so ahb noch etwas im englischen Forum gelesen und mir soweit folgendes zusammengereimt:
2.5.7 --thread-input
Sorgt dafür, dass ein extra Thread für das Einlesen des Inputs verwendet wird, dies bringt nur etwas wenn die CPU nicht voll ausgelastet wird da die Daten nicht schnellgenug gelesen werden können. Hat man nicht mehrere CPUs kommt dies nur selten vor, wenn z.B. die Festplatte nicht nachkommt oder z.B. manche Daten über die GPU geschleift werden uns sich deshalb verzögern. Stellt man die thread > 1 wird die Option automatisch verwendet.


Sollte man aktivieren wenn die CPU nicht voll ausgelastet werden.
Kommentare ?

Cu Selur

[Kopernikus]

Aus dem englischen Forum von pengvado persönlich:

"On that topic, is there any real situation in which someone wouldn't want to use --thread-input?"
If input is piped from another program. That's inherently multithreaded, and the data to read is already in memory, so --thread-input will only increase the syncing overhead.
Or if the avisynth script is really cpu-bound.

[Selur]

d.h. Wenn die Daten über ein schon multithreaded eingelesen werden oder man ein sehr CPU lastiges avisynth script hat sollte man --thread-input nicht nutzen. Hmm, das könnte ich oben noch anmerken. Allerdings muß ich sagen, dass ich bis dato persönlich noch keinen Fall konstruieren konnte wo das Feature bei thread = 1 (und single cpu) geholfen hätte.

Cu Selur

[akapuma]

Hallo,

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

Gruß

akapuma

[LigH]

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

[JoeB]

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 :( )

[Selur]

http://de.wikipedia.org/wiki/MIPS_%28Einheit%29

[LigH]

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

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

[Selur]

LOL, wollte eigentlich beide Links gepostet haben und auch auf die Architektur hingewiesen haben,... hatte ich aber wohl nur im Geiste gemacht :P

[JoeB]

@ Selur & Ligh

Danke :)

[Selur]

Kann wer etwas mehr zu "--no-dct-decimate" sagen als im Changelog steht?

Bringt es etwas das Feature zu nutzen?

[sade]

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

[sade]

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.

[akapuma]

Kann wer etwas mehr zu "--no-dct-decimate" sagen als im Changelog steht? 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.Hat jemand dazu schon Test gemacht? Ein kleiner Testclip mit trellis 1 wurde mit --no-dct-decimate fast 6% größer.

Gruß

akapuma

[LigH]

Das hat Kopernikus besser erklärt (http://forum.gleitz.info/showpost.php?p=312525&postcount=71) als ich zunächst verstanden hatte.

[akapuma]

Das hat Kopernikus besser erklärt (http://forum.gleitz.info/showpost.php?p=312525&postcount=71) als ich zunächst verstanden hatte.Dann zitiere ich mal hieraus, in der Annahme, daß ich hier im richtigen Thread bin: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":Standardmäßig ist bei B-Frames diese Dezimierung immer deaktiviert und bei Trellis immer anWenn 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

[LigH]

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

[akapuma]

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

akapuma

Edit: hier (http://www.digital-digest.com/articles/x264_options_page6.html) gefunden:
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})Das war's dann, oder?

Gruß

akapuma


Edit2: Zitat von hier (http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html):it's (trellis) unpredictability in Constant Quantizer modeunpredictability=unberechenbar

So sehe ich das auch: "Entweder DCT Decimation oder Trellis RD" würde ich auch so herauslesen.Und nochmal Zitat vom Link hiervor: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

[Selur]

unpredictability=unvorhersehbar ;)

=> kommende Zusatz für's man x264:
Trellis sollte deaktiviert werden wenn man crf oder einen single pass constant quantizer Encode durchführt, da seine Arbeitsweise hier nicth vorhersehbar ist.

schon vorhandene Anmerkung im man x264:
Sollte normalerweise mit --no-dct-decimate aufgerufen werden, falls man trellis verwendet.


----

Das war's dann, oder?
Falls Du die Zeit hast wäre es cool wenn Du noch nen PSNR/SSIM Vergleich bei gleicher Größe machen könntest. Soweit ich mich entsinne, gab es sowas mal im englischen Doom9 Forum, aber ich finde es nicht mehr. ;)

Cu Selur

[akapuma]

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.

[LigH]

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

[Selur]

Was passiert denn wenn man --no-dct-decimate und --no-fast-pskip benutzt?
Bis dato halte ich das auch für einen gangbaren Weg.

--no-past-pskip deaktiviert ja nur eine frühzeitigen Suchabbruch bei P-Frames soweit ich mich entsinne, dass sollte eigentlich separat zu --no-dct-decimate und trellis zu betrachten sein.

So wie ich es verstehe gibt es eine Art Schleife in der DCT-Dezimierung oder Trellis läuft und deren Berechnung noch eine zusätzliche Abbruchbedingung (fast p-skip) hat.

Cu Selur

[akapuma]

Was passiert denn wenn man --no-dct-decimate und --no-fast-pskip benutzt?
Bis dato halte ich das auch für einen gangbaren Weg.Würde ja meiner obigen Theorie, maximal eins zu benutzen, nicht widersprechen. "--no-dct-decimate --no-fast-pskip" heißt ja kein trellis, keine DCT-Dezimierung und kein fast P-Skip (also nichts).

--no-past-pskip deaktiviert ja nur eine frühzeitigen Suchabbruch bei P-Frames soweit ich mich entsinne, dass sollte eigentlich separat zu --no-dct-decimate und trellis zu betrachten sein.
Zu fast-pskip schreibt DeathTheSheep:However, you may want to uncheck it for maximum quality if you decide to use Trellis. Doing so best allows Trellis to be the determining factor in what information gets dropped/skipped without interference from other options.Das würde meines Erachtens bedeuten, fast-pskip nicht in Verbindung mit trellis zu verwenden.

In wie weit die Kombination fast-pskip und DCT-Dezimierung (also nichts in der Commandline anzugeben) sinnvoll ist, weiß ich nicht. DeathTheSheep schreibt hierzu In this respect, DCT decimation is similar to Fast P-skip and Trellis in that it makes decisions regarding what information to ignore (if any).Gruß

akapuma

[Selur]

Hmmm,... alles nicht so klar, würde übrigens DeathTheSheep nicht unbedingt als Referenz nehmen, sondern eher im englischen Forum suchen DeathTheSheep vertut sich gerne mal. (<- öfter als ich ;))

Das würde meines Erachtens bedeuten, fast-pskip nicht in Verbindung mit trellis zu verwenden.
trellis ohne fast-p-skip wäre sicher optimal, aber auch mit fast p-skip sollte trellis noch richtig arbeiten. (es wird meines Erachtens nur früher abgebrochen, was eventuell eine etwas idealere Lösung verwirft)

-------

Mal sortiert:
1. Trellis 1|2 alleine (also -trellis 1|2 --no-dct-decimate --no-fast-pskip)
2. Trellis 1|2 mit fast p-skip (also -trellis 1|2 --no-dct-decimate)
3. DCT-Decimate alleine (also --no-fast-pskip)
4. DCT-Decimate mit fast p-skip (also default verhalten)

Angemerkt sei, dass die Stufen sich nur selten wirklich im Resultat unterscheiden dürften.

Was mich interessiert wäre:
Was passiert wenn man nur "--no-dct-decimate" oder "--no-dct-decimate --no-fast-pskip" aufruft. ;)
Wie hoch sind die Unterschiede der 6 Stufen (Trellis 1|2 nicht vergesen) PSNR/SSIM mäßig wirklich. (vermute das tut sich alles nicht viel ;))

Cu Selur

[LigH]

Wenn ich dran denke, kann ich das ja mal z.B. an den progressiven VQEG-Clips probieren. Aber frühestens heute Nacht wohl...

[Kopernikus]

Aus meinem Verständnis heraus sollten sich Mode Decision (P-Skip) und Quantisierung (Trellis/DCT-decimate) nicht beißen, aber ich habe da weder Tests gefahren, noch wirkliche Praxiserfahrung.

Die beiden Optionen greifen an ganz unterschiedlichen Stellen im Encodingvorgang, einmal bei der Entscheidung des Makroblocktyps, und einmal bei der Quantisierung der Koeffizienten, ich sehe da keinen Grund, warum sich das beißen sollte.

[JoeB]

Aus meinem Verständnis heraus sollten sich Mode Decision (P-Skip) und Quantisierung (Trellis/DCT-decimate) nicht beißen, aber ich habe da weder Tests gefahren, noch wirkliche Praxiserfahrung.

Die beiden Optionen greifen an ganz unterschiedlichen Stellen im Encodingvorgang, einmal bei der Entscheidung des Makroblocktyps, und einmal bei der Quantisierung der Koeffizienten, ich sehe da keinen Grund, warum sich das beißen sollte.

Also könnte man ja eigentlich --no-fast-pskip immer drin lassen oder?

[Kopernikus]

Würde ich vermuten. Damit wird bei der Entscheidung, ob ein Block geskippt (also der entsprechende Block aus dem vorherigen Frame verwendet wird) oder nicht eine frühzeitige Entscheidung verhindert. Diese spart einige Vergleiche und ist deshalb schneller, aber anscheinend haut sie manchmal daneben und verursacht Blöcke.

Wie gesagt, ich habs nicht getestet, und Video Codecs sind sehr komplex, so dass scheinbar nicht zusammenhängende Dinge unerwartete Auswirkungen haben können. Sieh meine Aussagen deshalb eher als "educated guess" als als absolute Wahrheiten.

[Selur]

Bis dato habe ich noch keine Probleme gehabt, wenn ich --no-fast-pskip immer drin lasse. ;)

Cu Selur

[akapuma]

Bis dato habe ich noch keine Probleme gehabt, wenn ich --no-fast-pskip immer drin lasse. ;)Was für Probleme sollte es auch geben?

Gruß

akapuma

[Selur]

Qualitativ wahrnehmbare Unterschiede meinte ich. ;)
(hatte vor ner Weile, als die Option neu war, ein paar rein visuelle Tests gemacht, leider aber nicht PSNR&SSIM berechnen lassen :()


--------------

Das sollte also wie folgt laufen:
1. Entscheidung ob ein Makroblock aus anderen Makroblöcken 'zusammengesetzt' werden muss oder nicht.
- hier schlägt fast-pskip zu
2. Falls er aus anderen Makroblöcken 'zusammengesetzt' werden soll wird nun per DCT oder Trellis entschieden wie.

=> wir brauchen ein paar Tests :)

Cu Selur

Ps.: Bin erst Anfang des Jahres wieder bei mir am Hauptrechner mit genug Zeit, d.h. wenn jemand die Zeit hat wäre es schön wenn er ein paar Test machen könnte. ;)

[Eastermeyer]

d.h. wenn jemand die Zeit hat wäre es schön wenn er ein paar Test machen könnte.
Hier... http://cosgan.de/images/smilie/froehlich/e010.gif http://cosgan.de/images/smilie/verschiedene/a070.gif
Ich hab Zeit ohne Ende.

Sag mir mal welche Parameter-Kobinationen ich testen soll , bitte.

[Kopernikus]

Wie wäre es mit allen Kombinationen von dct-decimate, trellis (1,2) und no-fast-p-skip. Das sollten 12 sein. Das noch mit 1 bis 3 verschiedenen Materialien (anime, DVD, DVB oder so), dabei SSIM PSNR und fps und eine kurze visuelle Begutachtung bei 2 oder 3 verschiedenen Bitraten. Das sind zwischen 24 und 108 Encodes. Vielleicht mal mit einem Clip und einer Bitrate anfangen und falls sich spannende Dinge finden, kann man da ja weitertesten.

[Selur]

Daran denken: 2pass Encoding! :)

Cu Selur

[nexustheoriginal]

Hier... http://cosgan.de/images/smilie/froehlich/e010.gif http://cosgan.de/images/smilie/verschiedene/a070.gif
Ich hab Zeit ohne Ende.zwischen 24 und 108 EncodesDaran denken: 2pass Encoding! :)@Eastermeyer: Damit kriegst du die Ferien bestimmt schnell rum, oder? :D

[Bumsfalara]

Ähm. Hmmm.


Trellis nur bei 2-Pass encoding anwenden? Was ist mit crf? Wer nett, wenn man das auch noch testen könnte. Ich wäre auch zur Unterstützung bereit, wenn man die Quelle irgendwo hochladen könnte :)

[akapuma]

Hab mal was zu trellis und crf gegoogelt und das gefunden:

Zitat von Manao (http://forum.doom9.org/archive/index.php/t-105904.html):
Trellis is an option that, with a fixed quantizer, or fixed pseudo quality ( crf ), can either raise or lower the quality, and lower or raise the bitrate. But, with a fixed size, trellis raises the quality, and with a fixed quality ( here, quality = PSNR ), trellis reduces the size.

Gruß

akapuma

[Selur]

hatten wir das mit trellis nicht schon einiges Vorher schon geklärt?

[akapuma]

hatten wir das mit trellis nicht schon einiges Vorher schon geklärt?Naja, Bumsfalara zweifelt wohl noch.

Ich hatte 2 Stellen gefunden, in denen von der Kombination Trellis + CQ gewarnt/abgeraten wird. Zu Trellis + CRF gibt's nur das Zitat von Manao. Ich war davon ausgegangen, das CQ und CRF in Bezug auf Trellis als gleich anzusehen sind. Mehr haben wir nicht.

Zu Trellis und 2-Pass: Bei XviD ist es so, daß Trellis beim 2-Pass-Verfahren beim 1st pass automatisch deaktiviert wird (siehe Wissenswertes). Ist das vielleicht auch auf x264 anwendbar? Gehört Trellis vielleicht nur ein einen zweiten oder dritten Pass?

Gruß

akapuma

[Selur]

Das Zitat von Mano bezieht sich aber nur darauf wie Trellis an sich funktioniert. (Wenn ich mich richtig an den Thread erinnere ging es da nicht um ne bestimmte Implementierung ;) )

Zumindest MeGui behält den Trellis Parameter auch im 1st pass dabei. ;)

Denke für Vergleiche sollte 2pass mit einer festen Dateigröße verwendet werden. Vor allem, da dies noch die am meist verbreitetste Verwendung von x264 ist. ;)

Cu Selur

[akapuma]

Vor allem, da dies noch die am meist verbreitetste Verwendung von x264 ist.Warum nur??? CRF hat doch viele Vorteile:

1. Man spart viel Zeit. Die kann man zur Zeitersparnis nutzen und bessere Optionen nehmen. Mit CRF und "--me umh --merange 32" bin ich immer noch scheller als mit "--me hex" beim 2-Pass-Verfahren.

2. Das lästige und ungenaue Abschätzen der Zielgröße/Bitrate entfällt.

Vorerst werde ich aber sicherheitshalber auf die Kombination CRF + Trellis verzichten.

Gruß

akapuma

[LigH]

Sicherlich ist CRF die empfehlenswerte Variante -- wenn einem die Größe des Ergebnisses egal ist.

Wer aber auf ~ 100 KB genau eine Zielgröße erreichen will, dem wird kein wirkliches 1-Pass-Verfahren glücklich machen: Entweder die Größe stimmt höchstens zufällig, oder die Qualität schwankt.

[Bumsfalara]

Warum nur??? CRF hat doch viele Vorteile:

1. Man spart viel Zeit. Die kann man zur Zeitersparnis nutzen und bessere Optionen nehmen. Mit CRF und "--me umh --merange 32" bin ich immer noch scheller als mit "--me hex" beim 2-Pass-Verfahren.

2. Das lästige und ungenaue Abschätzen der Zielgröße/Bitrate entfällt.

Vorerst werde ich aber sicherheitshalber auf die Kombination CRF + Trellis verzichten.

Gruß

akapuma
Ich werde das mit crf und trellis testen. 2 Pass ist bei mir aus der Mode gekommen, seitdem ich die Leistungsfähigkeit von crf wirklich begriffen und ertestet habe.


Wie gesagt, ich bräuchte nur ne Quelle, dann teste ich alle Möglichkeiten durch.

Ich hab hier nen E6300 auf 2,8GHZ im Rechner, der hat genügend Reserven um sowas mal zu testen. Nur ne ordentliche Quelle hab ich nicht.

[Selur]

Wie gesagt, ich bräuchte nur ne Quelle, dann teste ich alle Möglichkeiten durch.Nimm z.B. Elephants Dream

oder was von hier:
http://www.w6rz.net/

[Bumsfalara]

Nimm z.B. Elephants Dream

oder was von hier:
http://www.w6rz.net/
Gut

Ich kenn die Datei noch nicht, nehme jetzt aber einfach mal diese hier:
http://www.w6rz.net/parkrun1920_23mbps.ts



Edit: Die Quelle ist etwas suboptimal, keine schnellen Bewegungen, nichts. Naja, ich werd schon nochwas finden.

[Selur]

Sollte eigentlich egal sein wie die Szenen aussehen, den PSNR/SSIM Werten und Trellis ist es ja egal wie das Material aussieht,...

Cu Selur

[Bumsfalara]

Gut, hab jetzt mal nen Test gemacht.

Ausgangsmaterial ist hochwertiges HD-Filmmaterial, heruntergerechnet auf 1280x720. Außerdem wurde deinterlaced.
Getestet wurden sowohl 2-Pass verfahren als auch die crf Methode.



avs-script

DGDecode_mpeg2source("F:\x264 test\x264 test.d2v")
tfm(order=1).tdecimate()
crop( 0, 0, -4, -2)
Lanczos4Resize(1280,720)



2-Pass Kommandozeile
--pass 2 --bitrate 1000 --stats "F:\x264 test\x264 test.stats" --ref 3 --mixed-refs (--no-fast-pskip) --bframes 3 --b-pyramid --bime --weightb --direct auto --filter -2,-2 (--trellis 2) --analyse all --8x8dct --vbv-maxrate 25000 --threads 2 --thread-input --progress (--no-dct-decimate) --output "F:\x264 test\x264 2pass 0-1-1.mp4" "F:\x264 test\x264 test.avs"


Crf Kommandozeile
--crf 22 --ref 3 --mixed-refs (--no-fast-pskip) --bframes 3 --b-pyramid --bime --weightb --direct auto --filter -2,-2 (--trellis 2) --analyse all --8x8dct --vbv-maxrate 25000 --threads 2 --thread-input --progress (--no-dct-decimate) --output "F:\x264 test\x264 2-1-1.mp4" "F:\x264 test\x264 test.avs"



Als Hilfsprogramm habe ich Megui in der Version 0.2.4.1026 benutzt.
x264 lag in der Version r614-1 vor.




Da ich absolut eine Null auf dem Gebiet Microsoft Excel (o.ä.) bin, habe ich es nicht geschafft das ganze als Diagramm darzustellen. Darher die kleine pdf am Ende dieses Posts.



Mein Persönliches Fazit: Unter crf schwanken die Größen der Einzelnen Dateien teilweise sehr stark. 0-0-0 ist hierbei am kleinsten, liefert aber allen Anschein nach die schlechteste Qualität. Das beste Ergebnis scheinen hier 2-0-0 (1-0-0) und 0-0-1 zu liefern. Auffällig und für meine begrenzten Kenntnisse merkwürdig ist es, dass ob Trellis 1 oder 2 gewählt ist keinerlei Unterschied macht.


Mehr hab ich jetzt aus mangelnder Zeit noch nicht ausgewertet. Wer noch mehr mit den Ergebnisse anfangen will, kann sich auch die Orginal .ods zu gemüte führen.

[housekat]

Vielen Dank für Deinen Test!
Jetzt gibts mal eine Basis auf die man sich beziehen kann. Selber habe ich zwar schon trellis/pskip/decimate durchprobiert und nie grosse Unterschiede in der Qualität gefunden. Hatte aber nie den gleichen Film in allen Varianten durchprobiert, daher herzlichen Dank.

Müsste man die Ergebnisse von PSNR/SSIM nicht noch auf die letzlich vom codec verwendete Bitrate normalisieren? Damit wäre der Unterschied noch geringer.
Denke aber das sich PSNR/Bitrate nicht linear verhalten und sich nicht trivial normalieren lässt. Oder lieg ich da jetzt ganz falsch?

[Bumsfalara]

Vielen Dank für Deinen Test!
Jetzt gibts mal eine Basis auf die man sich beziehen kann. Selber habe ich zwar schon trellis/pskip/decimate durchprobiert und nie grosse Unterschiede in der Qualität gefunden. Hatte aber nie den gleichen Film in allen Varianten durchprobiert, daher herzlichen Dank.

Müsste man die Ergebnisse von PSNR/SSIM nicht noch auf die letzlich vom codec verwendete Bitrate normalisieren? Damit wäre der Unterschied noch geringer.
Denke aber das sich PSNR/Bitrate nicht linear verhalten und sich nicht trivial normalieren lässt. Oder lieg ich da jetzt ganz falsch?
Naja, die Unterschiede in der Qualität sind ja auch marginal.

Ich stelle mir außerdem die Frage, ob SSIM und PSNR wirklich die Unterschiede zwischen no-fast-p-skip und fast-p-skip erfassen kann.
Ich denke, dass ist eher ein subjektives empfinden (bessere Himmel etc).

[housekat]

Zumindest die SSIM gibt ein bisschen Auskunft über die "subjektiv empfundene Qualität". Ist aber eh so, das sowohl PSNR als auch nur SSIM Bewertungen sind die unser "psychovisuelles System" nicht nachbilden können.
Das mit "besseren Himmel" ist auch meine Motivation. Ich encode eher alte Filme und möchte soviel "originale Unreinheiten" als möglich behalten.
Die diskutierten Parameter helfen dabei ein wenig. Auffällige Unterschiede zwischen no-fast-p-skip und fast-p-skip habe ich bisher noch nie bemerkt.
Sinnvoll wäre vermutlich Einzelsequenzen von Testfilmen zu encoden und dann möglichst viele Personen im ABX Verfahren bewerten lassen. Bisschen Aufwand halt ...

Als Auswahlkriterium hätten wir noch den Geschwindigkeitsunterschied. Zwischen 0-1-0 und 0-0-1 wird wohl kein Unterschied gewesen sein, aber zwischen 1-0-0 und 0-0-1 ? Das wäre vielleicht auch noch interessant zu wissen.

Vielleicht noch eine rein subjektive Bewertung von Dir:
Habe mir das ParkRun nicht runtergeladen-etwas gross, aber möglicherweise sind da Sequenzen mit Himmel u.ä. enthalten die Du (wenn Zeit&Lust) bewerten könntest.

[Bumsfalara]

Zumindest die SSIM gibt ein bisschen Auskunft über die "subjektiv empfundene Qualität". Ist aber eh so, das sowohl PSNR als auch nur SSIM Bewertungen sind die unser "psychovisuelles System" nicht nachbilden können.
Das mit "besseren Himmel" ist auch meine Motivation. Ich encode eher alte Filme und möchte soviel "originale Unreinheiten" als möglich behalten.
Die diskutierten Parameter helfen dabei ein wenig. Auffällige Unterschiede zwischen no-fast-p-skip und fast-p-skip habe ich bisher noch nie bemerkt.
Sinnvoll wäre vermutlich Einzelsequenzen von Testfilmen zu encoden und dann möglichst viele Personen im ABX Verfahren bewerten lassen. Bisschen Aufwand halt ...

Als Auswahlkriterium hätten wir noch den Geschwindigkeitsunterschied. Zwischen 0-1-0 und 0-0-1 wird wohl kein Unterschied gewesen sein, aber zwischen 1-0-0 und 0-0-1 ? Das wäre vielleicht auch noch interessant zu wissen.

Vielleicht noch eine rein subjektive Bewertung von Dir:
Habe mir das ParkRun nicht runtergeladen-etwas gross, aber möglicherweise sind da Sequenzen mit Himmel u.ä. enthalten die Du (wenn Zeit&Lust) bewerten könntest.
Ich habe nicht das Parkrun encodet, sondern nen Privaten HD Clip, den ich als wesentlich geeigneter angesehen habe :)

Vom Subjektiven Empfinden gefällt mir 2-0-1 am absolut besten.


Von den FPS waren alle 2-x-x und 1-x-x alle auf etwa 3,5-3,7FPS. Alle 0-x-x hatten an die 4.1-4.3 FPS (crf). Im 2-pass verhält es sich ähnlich.

[akapuma]

Darf ich mal dumm fragen:
Was ist besser, größere oder kleinere PSNR und SSIM-Werte (Google brachte zwar ausführliche Beschreibungen und Formeln, aber nicht die einfache Antwort auf diese Frage).

Gruß

akapuma

[housekat]

Danke für die Hinweise! Werd ich mal in meine scripts einfliessen lassen ...

[Bumsfalara]

Darf ich mal dumm fragen:
Was ist besser, größere oder kleinere PSNR und SSIM-Werte (Google brachte zwar ausführliche Beschreibungen und Formeln, aber nicht die einfache Antwort auf diese Frage).

Gruß

akapuma
Größere.

Sieht man eigentich schon daran, wenn man meine Ergebnisse vom crf und 2pass gegeneinander antreten lässt. Das Ergebnis crf ist wesentlich hochwertiger als des 2pass, welches auch nur mit einer Bitrate von 1000 arbeitet.

[Selur]

<table border="1" cellspacing="0" cols="6" frame="below" rules="groups"> <colgroup><col width="43"><col width="118"><col width="86"><col width="86"><col width="86"><col width="86"></colgroup> <tbody> <tr> <td align="left" height="25" width="43">
</td> <td align="left" width="118">
</td> <td align="left" width="86">
</td> <td align="right" width="86">
</td> <td align="left" width="86">
</td> <td align="right" width="86">
</td> </tr> </tbody> <tbody> <tr> <td align="center" height="17">Trellis</td> <td align="center">No-dct-decimation</td> <td align="center">No-fast-pskip</td> <td align="center">SSIM</td> <td align="center">PSNR</td> <td align="center">Bitrate</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9259247</td> <td sdval="37267" sdnum="1031;" align="right">37267</td> <td align="right">1008.50</td> </tr> </tbody> <tbody> <tr> <td sdval="2" sdnum="1031;" align="center" height="17">2</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9256851</td> <td sdval="37304" sdnum="1031;" align="right">37304</td> <td align="right">1009.91</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9256851</td> <td sdval="37304" sdnum="1031;" align="right">37304</td> <td align="right">1009.91</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9256419</td> <td sdval="37279" sdnum="1031;" align="right">37279</td> <td align="right">1008.01</td> </tr> </tbody> <tbody> <tr> <td sdval="2" sdnum="1031;" align="center" height="17">2</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9256419</td> <td sdval="37279" sdnum="1031;" align="right">37279</td> <td align="right">1008.01</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9255352</td> <td sdval="37279" sdnum="1031;" align="right">37279</td> <td align="right">1007.89</td> </tr> </tbody> <tbody> <tr> <td sdval="2" sdnum="1031;" align="center" height="17">2</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9255352</td> <td sdval="37279" sdnum="1031;" align="right">37279</td> <td align="right">1007.89</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9254644</td> <td sdval="37228" sdnum="1031;" align="right">37228</td> <td align="right">1006.85</td> </tr> </tbody> <tbody> <tr> <td sdval="2" sdnum="1031;" align="center" height="17">2</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9249624</td> <td sdval="37252" sdnum="1031;" align="right">37252</td> <td align="right">1008.35</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9249624</td> <td sdval="37252" sdnum="1031;" align="right">37252</td> <td align="right">1008.35</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9244073</td> <td sdval="37091" sdnum="1031;" align="right">37091</td> <td align="right">1008.97</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9241560</td> <td sdval="37082" sdnum="1031;" align="right">37082</td> <td align="right">1007.73</td> </tr> </tbody> </table>

Ich hab die 2pass Ergebnisse mal nach SSIM Werten sortiert.

1. schön zu sehen, dass no-fast-pskip zu helfen scheint.
2. Anfangs überraschend fand ich, dass Trellis bei den SSIM Werten eher negativ auffällt, die PSNR Werte scheinen aber davon zu profitieren. Wird Trellis nur auf PSNR Werte optimiert? Okay, das Trellis wenig macht war zu erwarten. Und das Trellis 1&2 sich nicht unterscheiden hatte ich auch vermutet.
3. Erstaunlich finde ich das das Deaktivieren der DCT-Decimation auch eher negativ ist unabhänig von Trellis.

Es ergibt sich also aus diesen Ergebnissen folgende Reihenfolge:
(gut nach schlecht)
1. Trellis: off , no-dct-decimation: off, no-fast-pskip: on
2. Trellis: on , no-dct-decimation: off, no-fast-pskip: on
3. Trellis: on , no-dct-decimation: on, no-fast-pskip: on
4. Trellis: on , no-dct-decimation: on, no-fast-pskip: off
5. Trellis: off , no-dct-decimation: on, no-fast-pskip: off
6. Trellis: on , no-dct-decimation: off, no-fast-pskip: off
7. Trellis: off , no-dct-decimation: on, no-fast-pskip: on
8. Trellis: off , no-dct-decimation: off, no-fast-pskip: off

=> no-fast-pskip sollte immer an sein

Cu Selur

Ps.: bräuchten vermutlich einiges mehr an Tests um wirklich verlässliche Schlussfolgerungen ziehen zu können.
Schön ist auf jeden Fall zu sehen, dass die Einstellungen relativ wenig machen. ;)

[housekat]

SSIM von 1 wäre optimal. PSNR ist ein Signal/Rauschverhältnis, daher besser wenn gross (viel gutes Signal zu wenig rauschen).
SSIM bringt ein bisschen "subjektive menschliche" Bewertung mit rein und sagt daher zumindest imho mehr aus wie PSNR.

[Bumsfalara]

<table border="1" cellspacing="0" cols="6" frame="below" rules="groups"> <colgroup><col width="43"><col width="118"><col width="86"><col width="86"><col width="86"><col width="86"></colgroup> <tbody> <tr> <td align="left" height="25" width="43">
</td> <td align="left" width="118">
</td> <td align="left" width="86">
</td> <td align="right" width="86">
</td> <td align="left" width="86">
</td> <td align="right" width="86">
</td> </tr> </tbody> <tbody> <tr> <td align="center" height="17">Trellis</td> <td align="center">No-dct-decimation</td> <td align="center">No-fast-pskip</td> <td align="center">SSIM</td> <td align="center">PSNR</td> <td align="center">Bitrate</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9259247</td> <td sdval="37267" sdnum="1031;" align="right">37267</td> <td align="right">1008.50</td> </tr> </tbody> <tbody> <tr> <td sdval="2" sdnum="1031;" align="center" height="17">2</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9256851</td> <td sdval="37304" sdnum="1031;" align="right">37304</td> <td align="right">1009.91</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9256851</td> <td sdval="37304" sdnum="1031;" align="right">37304</td> <td align="right">1009.91</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9256419</td> <td sdval="37279" sdnum="1031;" align="right">37279</td> <td align="right">1008.01</td> </tr> </tbody> <tbody> <tr> <td sdval="2" sdnum="1031;" align="center" height="17">2</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9256419</td> <td sdval="37279" sdnum="1031;" align="right">37279</td> <td align="right">1008.01</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9255352</td> <td sdval="37279" sdnum="1031;" align="right">37279</td> <td align="right">1007.89</td> </tr> </tbody> <tbody> <tr> <td sdval="2" sdnum="1031;" align="center" height="17">2</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9255352</td> <td sdval="37279" sdnum="1031;" align="right">37279</td> <td align="right">1007.89</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9254644</td> <td sdval="37228" sdnum="1031;" align="right">37228</td> <td align="right">1006.85</td> </tr> </tbody> <tbody> <tr> <td sdval="2" sdnum="1031;" align="center" height="17">2</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9249624</td> <td sdval="37252" sdnum="1031;" align="right">37252</td> <td align="right">1008.35</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9249624</td> <td sdval="37252" sdnum="1031;" align="right">37252</td> <td align="right">1008.35</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9244073</td> <td sdval="37091" sdnum="1031;" align="right">37091</td> <td align="right">1008.97</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9241560</td> <td sdval="37082" sdnum="1031;" align="right">37082</td> <td align="right">1007.73</td> </tr> </tbody> </table>

Ich hab die 2pass Ergebnisse mal nach SSIM Werten sortiert.

2. Anfangs überraschend fand ich, dass Trellis bei den SSIM Werten eher negativ auffällt, die PSNR Werte scheinen aber davon zu profitieren. Wird Trellis nur auf PSNR Werte optimiert? Okay, das Trellis wenig macht war zu erwarten. Und das Trellis 1&2 sich nicht unterscheiden hatte ich auch vermutet.

Was lässt sich daraus schließen?
Das Trellis2 es den Performanceverlust gar nicht wert ist? Oder ein Fehler in der Revision. Ich mein, man muss sich mal überlegen: Insgesamt 16 Encodes mit Trellis, die sich jeweils untereinander in Bezug auf Trellis von der messbaren Qualität nicht unterscheiden.

Wozu also Trellis 2?

3. Erstaunlich finde ich das das Deaktivieren der DCT-Decimation auch eher negativ ist unabhänig von Trellis.

Cu Selur

Deckt sich eigentlich mit meinen subjektiven Erfahrungen.




Edit: Nochmals thema Trellis: Man sollte da auch nicht vergessen, die Änderung der Bitrate zu vergleichen.

Prozentual mal der Unterschied zwischen 2-0-1 (1-0-1) und 0-0-1 auseinandergenommen.

Der SSIM ist in etwa 0.036% schlechter.
Der PSNR ist in etwa 0.01% besser.
Die Bitrate ist ebenfalls um 0.01% besser.


Was mich wegen der engen Relation von PSNR und Bitrate zu einem weiteren Vergleich bringt:

Höchste Bitrate (2-0-1) gegen niedrigste Bitrate (0-0-0) PSNR Vergleich:

PSNR liegt um 0.01% auseinander (2-0-1 0.01% besser)
Die Bitrate liegt 0.01% auseinander.
SSIM liegt um 0.01% auseinander, ist im Gegensatz zum Vergleich oben also schlechter.

Hm: Ich werde mal versuchen die ganze Relation irgendwie Graphisch dazustellen.

[Kopernikus]

Trellis 2 ist eine Sonderform von Trellis 1, bei der jeder Encodiermodus, der in Betracht gezogen wird "trellisiert" wird, bei Trellis 1 nur die, die schlussendlich ausgewählt wurden.

Dass Trellis 1 nicht wesentlich schlechter ist, zeigt, dass die Auswahlheuristiken gut sind, und sich durch Trellis nicht wesentlich durcheinanderbringen lassen.

Trellis 2 sollte man genau wie -me esa und -qpfile als Option sehen, die für Experimente interessant, aber im Alltag nicht nötig sind.

[Selur]

Yup, sehe es auch so, dass bei Trellis eher die Frage ist ob es aktiviert ist oder nicht und nicht ob Trellis 1 oder 2 daran ist.

Nochmals thema Trellis: Man sollte da auch nicht vergessen, die Änderung der Bitrate zu vergleichen.
die minimale Schwankungen sehe ich als nicht bewertenswert an (Ich rede hier vom 2pass Encoding, für 1pass Verfahren siehe Aussagen von hier: http://forum.gleitz.info/showpost.php?p=312890&postcount=36)

Cu Selur

[Bumsfalara]

Hm, mich interessiert das jetzt mit der Abhängigkeit von Bitrate zu PSNR und Bitrate zu SSIM, ohne Rücksicht auf gewählte Einstellungen.

Hier mal ein Vergleich



Das sind zwar nur Nuancen, aber dennoch korreliert PSNR eher mit der Bitrate als SSIM.

Ich mache jetzt nochmal einen test, das wird spaßig :D




Edit: Gut, vergesst das. Mein Verdacht hat sich als ziemlich falsch erwiesen :(

[Selur]

Das sind zwar nur Nuancen, aber dennoch korreliert PSNR eher mit der Bitrate als SSIM.
Sorry, aber für meinen Geschmack sind die Schwankungen zu klein als das man da was rausinterpretieren kann. ;)

[Bumsfalara]

Sorry, aber für meinen Geschmack sind die Schwankungen zu klein als das man da was rausinterpretieren kann. ;)
Siehe mein Edit oben :)

[Selur]

*gig* wenn Du die Zeit und Muße hast wären noch ein paar Tests sicher interessant. Normales DVD/DVB Material sollte als Quelle durchaus reichen, wenn wir nur die PSNR und SSIM Werte angucken. ;)

Cu Selur

[Bumsfalara]

*gig* wenn Du die Zeit und Muße hast wären noch ein paar Tests sicher interessant. Normales DVD/DVB Material sollte als Quelle durchaus reichen, wenn wir nur die PSNR und SSIM Werte angucken. ;)

Cu Selur
Ja, ich lass grad schon nen Test mit dem Parkwalk@1280x1080 23mbps laufen.


Elephants Dream werd ich mir nicht vornehmen, das dauert bei dem viel zu lange, keine Ahnung warum.


Edit: Parkwalk ist zum vergessen, der ist voller interlacing, das Material ist einfach scheiße. x264 kommt damit 0 zurecht und es dauert ewig.


Ich nehm doch elephants dream. Ist auch gar nicht so schlecht, weil das Quellmaterial von Parkwalk un meinem eigenen sich ähneln.

[Bumsfalara]

Gut, der Test ist fertig.

Diesmal gemacht mit der 1024er Version vom Elephants Dream, die als avi vorlag.

Erstmal das Avisynth script
DirectShowSource("F:\x264 test\ED_1024.avi",fps=24,audio=false)Und die x264 Commandline
--pass 2 --bitrate 1000 --stats "F:\x264 test\elephants dream.stats" --ref 4 --mixed-refs (--no-fast-pskip) --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 (--trellis 1) --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 2 --thread-input --progress (--no-dct-decimate) --output "F:\x264 test\elephants dream 2pass1-1-1.mkv" "F:\x264 test\elephants dream.avs"Auf Grund der nicht vorhandenen Unterschiede zwischen Trellis1/2 habe ich auf einen Test mit Trellis2 verzichtet.

Die Ergebnisse sind unten wie gehabt als PDF und als .rar mit der original .ods angehängt.


Fazit (nur bei ssim betrachtung): no-fast-p-skip sollte eigentlich immer an sein, bringt nur Vorteile.
Trellis in Verbindung mit no-dct-decimation ist mit Vorsicht zu genießen. Die besten Ergebnisse werden erzielt, wenn man beides getrennt verwendet. Ein Gegenbeispiel ist der Rückschritt von 1-1-1 auf 1-0-1. Allerdings ist dieser denke ich eher darauf zurück zu führen, dass der Film gut mit no-dct-decimation "zusammenarbeitet".

Fazit (PSNR): Trellis ist ist super. no-fast-p-skip nur in Zusammenarbeit mit no-dct-decimation zu genießen.

Fazit FPS: no-dct-decimation beschleunigt in den meisten Fällen den Encoding Vorgang bzw. bremst ihn nicht aus (1-0-1 zu 1-1-1). Aber Ernsthaft: Wen kümmern da noch FPS? Sind wir nicht alle Qualitätsfanatiker? Ich für meinen Teil schon, deswegen hab ich meinen Conroe als Rechenmonster.

Mein Persönliches Fazit: Nunja, was soll man dazu noch sagen? PSNR und SSIM widerlegen sich teilweise Gegenseitig. Die FPS sind mir total egal.

Ansonsten: no-fast-p-skip einfach IMMER an. Trellis 1 kann helfen, tut es meistens auch -> Ich werds immer an machen im 2-pass. no-dct-decimation ist mir zu instabil, wenn man das Ergebnis mit dem Vorangegangen betrachtet. Es scheint manchmal die Qualität zu steigern, manchmal zu senken. Im Zusammenspiel mit Trellis wird es absolut unberechenbar.





Ansonsten habe ich nochmals einen crf Test gemacht, dürfte auch ganz interessant sein. Da ich aber keine Lust habe, den jetzt nochmals für euch auszuwerten, hier ne kurze Zusammenfassung:

Commandline
--crf 22 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --bime --weightb --direct auto --filter -2,-2 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --threads 2 --thread-input --progress


Trellis ist unbedingt zu deaktivieren!

Vergleich 1-0-1 zu 0-0-1
SSIM:0.9865501/0.9860802
PSNR:44.885/44.647
BITRATE:2070.64/2063.36
8.33 fps/9.21 fps

SSIm und PSNR sind zwar höher (0.1%), allerdings auf Kosten einer wesentlich höheren Bitrate. Mögen zwar ebenfalls nur Nuancen sein, aber wenn man sich noch die Geschwindigkeitssteigerung ansieht sollte man Trellis deaktiviert lassen, da es bei crf anscheinend nur zu einer Bitratensteigerung, nicht aber zu einer Qualitätssteigerung führt.





Zum Thema "Soll ich jetzt RDO wählen, 4 oder 5 Referenceframes oder doch lieber FPS vorziehen".

Hier mal die Werte von folgender crf22 commandline:
--crf 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 7 --analyse all --8x8dct --vbv-maxrate 25000 --me esa --threads 2 --thread-input --progress


SSIM:0.9860237
PSNR:44.717
Bitrate (!!):1919.36
5.79 fps

Gleiche Qualität wie oben bei 5% Bitrateneinsparung. Das kann sich mehr als sehen lassen.

Ist Vergleichbar zu crf21 mit der alten Commandline, sogar schneller von den FPS her..
Fazit: Denkt euch eins, hab jetzt genug. Ich werd bei crf22 mit allem möglichen extras an bleiben :)



So, jetzt bin ich fertig. Wenn ihr nochmals Tests wollt, gebt mir ne gescheite Quelldatei :)

[Selur]

Trellis in Verbindung mit no-dct-decimation ist nicht mit Vorsicht zu genießen.Also super?

no-fast-p-skip ist nur in Zusammenarbeit mit no-dct-decimation zu genießen.Da no-fast-pskip normalerweise an ist sollte man also auch no-dct-decimation an machen.

Die Ergebnisse sind unten wie gehabt als PDF und als .rar mit der original .ods angehängt.
nö,... :(

Cu Selur

[Bumsfalara]

Ach Selur, du bist einfach zu schnell für mich :D


Text ist jetzt überarbeitet und vollständig.

[Selur]

Ne, Du postest Beiträge bevor Du fertig bist ;)

damit nicht jeder runterladen muß:
<table border="1" cellspacing="0" cols="7" frame="box" rules="groups"> <colgroup><col width="43"></colgroup> <colgroup><col width="118"></colgroup> <colgroup><col width="86"></colgroup> <colgroup><col width="86"></colgroup> <colgroup><col width="86"></colgroup> <colgroup><col width="86"></colgroup> <colgroup><col width="86"></colgroup> <tbody> <tr> <td align="center" height="17" width="43">Trellis</td> <td align="center" width="118">No-dct-decimation</td> <td align="center" width="86">No-fast-pskip</td> <td align="center" width="86">SSIM</td> <td align="center" width="86">PSNR</td> <td align="center" width="86">Bitrate</td> <td align="center" width="86">FPS</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9772761</td> <td sdval="41773" sdnum="1031;" align="right">41773</td> <td align="right">1000.41</td> <td sdval="8,15" sdnum="1031;" align="right">8,15</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9772585</td> <td sdval="41838" sdnum="1031;" align="right">41838</td> <td align="right">1000.30</td> <td sdval="7,84" sdnum="1031;" align="right">7,84</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9770386</td> <td sdval="41787" sdnum="1031;" align="right">41787</td> <td align="right">1000.28</td> <td sdval="7,84" sdnum="1031;" align="right">7,84</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9770352</td> <td sdval="41786" sdnum="1031;" align="right">41786</td> <td align="right">1000.28</td> <td sdval="8,48" sdnum="1031;" align="right">8,48</td> </tr> </tbody> <tbody> <tr> <td sdval="1" sdnum="1031;" align="center" height="17">1</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9769949</td> <td sdval="41824" sdnum="1031;" align="right">41824</td> <td align="right">1000.30</td> <td sdval="8,55" sdnum="1031;" align="right">8,55</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9769763</td> <td sdval="41751" sdnum="1031;" align="right">41751</td> <td align="right">1000.41</td> <td sdval="8,88" sdnum="1031;" align="right">8,88</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="1" sdnum="1031;" align="center">1</td> <td align="right">0.9763066</td> <td sdval="41611" sdnum="1031;" align="right">41611</td> <td align="right">1000.40</td> <td sdval="7,99" sdnum="1031;" align="right">7,99</td> </tr> </tbody> <tbody> <tr> <td sdval="0" sdnum="1031;" align="center" height="17">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td sdval="0" sdnum="1031;" align="center">0</td> <td align="right">0.9762292</td> <td sdval="41612" sdnum="1031;" align="right">41612</td> <td align="right">1000.40</td> <td sdval="8,61" sdnum="1031;" align="right">8,61</td> </tr> </tbody> </table>

Cu Selur