Encoding-Speed: x264 vs xvid

Bumsfalara

Da ja grundsätzlich die Aussage, dass x264 sowohl zum Encoding als auch zum Decoding enorm viel Power braucht immer noch als gültiges Gesetz angesehen wird, würde ich diesen Thread ganz gern benutzen um das Gegenteil zu beweisen.

Anlass dafür ist ein 23min langer Ausschnitt des Filmes "Platoon", den ich aufgenommen habe. Ich hab ihn sowohl mit x264 als auch mit xvid-encraw encodieren lassen, um die Qualität zwischen beiden zu vergleichen. Was mich allerdings am Meisten faziniert hat, waren die Zeiten mit denen das von statten ging.

Die Einstellungen von xvid und x264 waren dabei jeweils sehr am Anschlag gewählt, bei x264 wäre natürlich noch wesenltich mehr gegangen, aber die Qualität allerdings nicht mehr sichtbar verbessert hätte sondern jediglich den Speed herabgesetzt hätte.

Noch schnell die Kommandozeile:

Code

XVIDStarting job job1 at 10:49:06Starting preprocessing of job...Preprocessing finished!encoder commandline:-i "D:\Platoon.avs" -pass1 "D:\Platoon.stats" -bitrate 1000 -kboost 100 -kthresh 3 -ostrength 0 -overhead 0 -max_key_interval 250 -nopacked -vhqmode 4 -qpel -gmc -closed_gop -lumimasking -imax 3 -pmax 4 -max_bframes 4 -bvhq -bquant_ratio 100 -bmax 4 -threads 0 successfully started encodingProcessing ended at 10:54:40Starting job job2 at 10:54:40Starting preprocessing of job...Preprocessing finished!encoder commandline:-i "D:\Platoon.avs" -pass2 "D:\Platoon.stats" -bitrate 1000 -kboost 100 -kthresh 3 -ostrength 0 -overhead 0 -max_key_interval 250 -nopacked -vhqmode 4 -qpel -gmc -closed_gop -lumimasking -imax 3 -pmax 4 -max_bframes 4 -bvhq -bquant_ratio 100 -bmax 4 -threads 0  -avi "D:\Platoon.avi"successfully started encodingProcessing ended at 11:34:36

Code

x264


Starting job job3 at 11:34:36
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
--pass 1 --bitrate 1000 --stats "D:\Platoon.stats" --bframes 16 --b-pyramid --direct auto --filter -2,-1 --subme 1 --analyse none --vbv-maxrate 25000 --me dia --merange 12 --threads auto --thread-input --progress --output NUL "D:\Platoon.avs" 
successfully started encoding
Processing ended at 11:41:22


Starting job job4 at 11:41:22
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
--pass 2 --bitrate 1000 --stats "D:\Platoon.stats" --ref 3 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --analyse all  --8x8dct --vbv-maxrate 25000 --me umh --merange 12 --threads auto --thread-input --progress --output "D:\Platoon.mp4" "D:\Platoon.avs" 
successfully started encoding
Processing ended at 12:10:42

Alles anzeigen

Pass1 ist xvid überlegen, aber dass im Pass2 x264 so davon zieht hätte ich nie gedacht. Der Thread ist jetzt nur schnell zusammengezimmert, ich hab da gar nichts groß getestet, im Grunde ist das eher ein Nebenprodukt eines Qualitätsvergleichs. Vielleicht interessiert es ja jemanden.

Didée

Probier' Xvid doch nochmal, aber ohne -gmc (GMC ist seeeeehr langsam, und bringt ca. 0,0000001% Qualitätsgewinn - das Konzept ist technisch interessant, aber i.d. Praxis eine sehr teure Nullnummer).
Ob vhq=4 viel bringt ist auch so ne Sache ... viele bevorzugen vhq=1 oder 2, und das ist dann nochmal deutlich schneller.

Der Metrik-Gläubige Saggittaire weist immer wieder darauf hin, dass (sinngemäß übersetzt) "x264 mit den schnellsten und schlampigsten Einstellungen immernoch "tausendmal besser" *) ist als zu Xvid mit allem-aktiviert-was-nur-geht."
*) "very much better, and by far" [Saggittaire]

(Was natürlich nur stimmen kann, wenn man mehr auf Zahlentabellen als auf das visuelle Ergebnis schaut.)

Witzig: Deine 2nd-pass Geschwindigkeiten erreiche ich nicht mal im 1st-pass. Was glaubst Du wie erst meine 2nd-pass Geschwindigkeiten aussehen...? :eek:

LigH

Insbesondere ist die 3-Warppoint-GMC-Unterstützung von XviD das vielleicht wichtigste Hindernis zur SAP-Kompatibilität.

Und ... Metriken sind immer falsch, im Vergleich zur subjektiven Wahrnehmung. Manche nur deutlicher als andere. ;D

Bumsfalara

Ich würd mich da jetzt nicht so auf dem gmc aufhängen.
Hab jetzt vhq 2 und gmcoff gewählt.

Code

Starting job job5 at 17:16:36Starting preprocessing of job...Preprocessing finished!encoder commandline:-i "D:\Platoon.avs" -pass1 "D:\Platoon.stats" -bitrate 1000 -kboost 100 -kthresh 3 -ostrength 0 -overhead 0 -max_key_interval 250 -nopacked -vhqmode 2 -qpel -closed_gop -lumimasking -imax 3 -pmax 4 -max_bframes 4 -bvhq -bquant_ratio 100 -bmax 4 -threads 0 successfully started encodingProcessing ended at 17:22:28Starting job job6 at 17:22:28Starting preprocessing of job...Preprocessing finished!encoder commandline:-i "D:\Platoon.avs" -pass2 "D:\Platoon.stats" -bitrate 1000 -kboost 100 -kthresh 3 -ostrength 0 -overhead 0 -max_key_interval 250 -nopacked -vhqmode 2 -qpel -closed_gop -lumimasking -imax 3 -pmax 4 -max_bframes 4 -bvhq -bquant_ratio 100 -bmax 4 -threads 0  -avi "D:\Platoon faster.avi"successfully started encodingProcessing ended at 17:49:53

Gut, schon schneller. Sogar an die 35%. Trotzdem: Im Vergleich zu x264, dessen Qualität in den meisten Fällen mindestens 30% besser ist ist das ziemlich schlecht für xvid. Für 30% gewinn an Qualität 30% längere Encodingzeit? -> Das nehm ich gern in Kauf.

In meinen Augen gibt es kein Argument mehr für xvid, außer SAP-Kompatibilität. Und ich bin mir sicher, dass man x264 so trimmen kann dass es xvid einholt und dennoch besser aussieht. Ich mach mich da mal dran

Edit: Gut, ich weiß, ich hab die Overflow Control Strenght unangetastet gelassen und da nichts verändert. Wollte xvid einfach mal machenlassen. Aber DAS Ergebnis ist dann doch etwas zu heftig.

Code

Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 696 x 416, 25.000fps (25/1), starting from frame 0
xvid [info]: Number of frames to encode: 35710, Bitrate = 1000kbps
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC 
xvid [info]: Detected cpus = 2, threads requested = 1, threads in use = 1
xvid [info]: Threaded input reading active


Tot: enctime(ms) =1640971.00,               length(bytes) =   335136949
Avg: enctime(ms) =  45.95, fps =  21.76, length(bytes) =        9383
I frames:    491 frames, size =  31537/   15484766, quants =  2 / 2.99 /  3
P frames:  19026 frames, size =  12742/  242440284, quants =  4 / 4.00 /  4
B frames:  16193 frames, size =   4768/   77211899, quants =  4 / 4.98 /  5
[B]desired video bitrate of this job: 1000 kbit/s - obtained video bitrate (approximate): 1881 kbit/s[/B]
----------------------

Alles anzeigen

Edit2: Bei x264 hatte ich beim Encodingvorgang die PSNR und SSIM Kalkulation an. Die muss weg.

Brother John

Auf welcher CPU codierst du denn? Multicore-Prozessor schätze ich?

Bei Encraw hast du --threads 0 angegeben, d.h. 1 Encodingthread plus 1 Thread für AviSynth, aber nur bei aktuellstem Encraw. Damit ist einer der CPU-Kerne für fast die gesamte Arbeit zuständig. x264 dagegen nutzt mit --threads auto --thread-input die Kerne viel besser aus. Unter den Umständen muss sich Xvid schwer tun.

Bumsfalara

Core2Duo E6300@2800mhz

Encraw lastet beide Kerne aus, ebenso wie x264. Im Taskmanager überprüft. In megui hab ich auch auf Thread2 gestellt, allerdings wird die Einstellung nicht so richtig übernommen. Beide Kerne sind bei Encraw etwa zu 75% ausgelastet.

-> Evtl sollte mal jemand mit nem Singelcore ein paar Tests laufen lassen?

katjarella

Zitat von Bumsfalara

Evtl sollte mal jemand mit nem Singelcore ein paar Tests laufen lassen?

Du kannst Doch dein system als Single-CPU starten lassen.
boot.ini bearbeiten und die Werte dran hängen. /ONECPU /NUMPROC=1
Denn ich brauch das manchmal, bei sehr sehr alten Programmen.

Brother John

Singlecore-Test mit einem Pentium M 1,6 GHz.
704×432, 12500 Frames.
XviD 1.2 (25.07.2007 celtic_druid)
Xvid_Encraw 31.08.2007
x264 rev 680 Cef
Komplette Logs im Anhang.

Zitat

xvid_encraw.exe -i "amelie.avs" -type 2 -nothreadedinput -pass1 "xvid.stats" -bquant_ratio 162 -bquant_offset 0 -qtype 1 -qmatrix "C:\Encoding\_Matrizen\EQM V3LR.xcm" -qpel -vhqmode 2 -bvhq -zones 0,w,1,O -progress 100

xvid_encraw.exe -i "amelie.avs" -type 2 -nothreadedinput -pass2 "xvid.stats" -avi "test-xvid.avi" -par 4 -overhead 0 -bitrate 1500 -bquant_ratio 162 -bquant_offset 0 -qtype 1 -qmatrix "C:\Encoding\_Matrizen\EQM V3LR.xcm" -qpel -vhqmode 2 -bvhq -zones 0,w,1,O -progress 100

Zitat

x264.exe --pass 1 --bitrate 1500 --stats "x264.stats" --bframes 16 --b-pyramid --direct auto --filter -2,-1 --subme 1 --analyse none --vbv-maxrate 25000 --me dia --merange 12 --threads 1 --progress --no-ssim --no-psnr --output NUL "amelie.avs"

mit RDO
x264.exe --pass 2 --bitrate 1500 --stats "x264.stats" --ref 3 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --merange 12 --threads 1 --progress --no-ssim --no-psnr --output "test-x264.mp4" "amelie.avs"

ohne RDO
kein --b-rdo, --subme 5, --me hex, Rest gleich

in Sekunden
...............1st...2nd...Summe
Xvid...........331...1133..1464
x264 mit RDO...541...2260..2801
x264 ohne RDO..541...1399..1940

Ich habe von den x264-Details zu wenig Ahnung, um die Konfig bis aufs Letzte zu optimieren. Zumindest bei sanfter Kompression scheint es gut möglich, beide Encoder auf ein ähnliches Geschwindigkeitsniveau zu bekommen. Das deckt sich auch mit meinen jüngsten x264-Spielereien. (Wenn es dem Ding nur nicht so verflucht lästig abzugewöhnen wäre, das Bild glattzubügeln! Aber lassen wir das, ist ein anderes Thema.)

Didée

Zitat von Brother John

(Wenn es dem Ding nur nicht so verflucht lästig abzugewöhnen wäre, das Bild glattzubügeln! Aber lassen wir das, ist ein anderes Thema.)

Das ist eben - bei relativ niedrigen(!) Bitraten - der Preis der schönen neuen Technik.
Dem x264 die Glättbügelei "abzugewöhnen" ist gar nicht schwierig, z.B.:
--no-deblock --deadzone-intra 1 --deadzone-inter 1

Und - TADAAA - die Glattbügelei ist weg.

Allerdings - TADAAA - sieht x264 dann schon wieder fast so aus wie Xvid ...

Das Quadrieren eines Kreises bleibt eben eine schwierige Sache.

Schön und hilfreich wäre es, wenn da ein Dekoder wäre, der folgendes macht:
ERST den aktuellen Frame OHNE Deblocking zur Ausgabe (Rendering) bringen. DANN den aktuell Frame deblocken und als Referenz für die nachfolgenden Frames verwenden.
Das erhielte die Effizienz-Vorteile des Inloop-Filters, vermiede aber größtenteils den typischen "Deblocking-Look".

Ist ein "uralter" Vorschlag von Manao ... und klingt so vielversprechend, dass es mich wundert, dass das noch niemand implementiert hat. Sooo schwierig kann das doch gar nicht sein!

Brother John

Tja, das ist tatsächlich so ein Problem mit dem eckigen Kreis ... obwohls bei mir schon 1/2-DVD-Bitraten sind: grob 2–2,5 Mbit. Kleiner muss das auch nicht werden. Insgesamt ist mir x264 wg. der feineren Quantizer-Abstufung recht sympatisch. Aber ob sich der Umstieg wirklich lohnt, das braucht noch einige Tests mit beiden Kandidaten. Die Encoding-Geschwindigkeit ist jedenfalls in so einer HQ-Situation kein schlagendes Argument für Xvid mehr.

Der Decoder-Vorschlag klingt wirklich sehr sinnvoll. Ich konnte mich noch nie und bei keinem Format mit irgendwelchem Postprocessing anfreunden. (Jaja, ist kein eigtl. Postprocessing bei H.264...)

Ich hab grad mal kurz über die Testvideos drübergeschaut. Bis auf den glatten x264-Look sind die qualitativ auf sehr ähnlichem Niveau. Wers nachvollziehen mag: »Die fabelhafte Welt der Amélie«, deutsche 2-DVD-Ausgabe, Skript:

Code

Crop(8,72,-8,-72)
trim(10001,22500)

LigH

Zitat von katjarella

boot.ini bearbeiten und die Werte dran hängen. /ONECPU /NUMPROC=1

Gute Idee... Ich kenne da Spiele, die bei Mehrkern-Prozessoren so richtig durcheinander geraten (z.B. SSam2). Da wäre so ein Bootmanager-Eintrag die einfachste Lösung (was hab ich nicht schon für OS- und EXE-Patches gefunden).

Bumsfalara

Hm, eventuell sollte man die Diskussion über den "glatten" x264-Look auslagern? Ich persönlich bin der Meinung, dass man den recht einfach wegbekommt, indem man den inloop-Deblocking-Filter recht weiter runtersetzt Bitraten im Bereich von 1300-1500kbit/s anstrebt.

Ich werd eventuell das Wochenende über noch ein paar Geschwindigkeittests laufen lassen, wenn Interesse besteht.

Jetzt mitmachen!