"Ultra" Qualität x264

Schon mal ein verdammt guter Ansatzpunkt:

http://forum.gleitz.info/showthread.php?t=20956

...und nein, der hornalte AVI-Container eignet sich nicht für MPEG-4 AVC.

"Nichtwissenheit" kann mit der Hilfe der gezielten Suche gelindert werden

Ach ja ist für x264 der *.avi Containier am geeignetsten ?

Nein, MP4 bzw. MKV sind geeigneter.

Programm würde ich MeGUI empfehlen. Dafür gibt es Profile, die für viele verschiedene Szenarien sehr gute Einstellungen liefern.

Rechenzeit ist unterschiedlich, je nach Einstellungen so zwischen 15 und 2 fps sollten es werden können mit deinem Rechner, also bei 2Pass zwischen 4 und 25fachen der Laufzeit des Films. "Ultra Qualität" also eher letzteres.

Audiocodec kannst du nehmen was du willst. Je nach Bitrate ist AAc oder Ogg besser.

Nö

eventuell noch ganz interessant:
http://forum.gleitz.info/showthread.php?t=25573

Ansonsten frag wenn etwas unklar ist,..

Einigen Leuten fehlt es wohl etwas an Phantasie ... wenn ich wissen will, ob es so was wie "Wissenswertes rund um x264" auch für die CLI-Version gibt, dann gebe ich in unsere Forensuche ein:

[ Wissenswertes x264 CLI ]

und erhalte als Ergebnus unter anderem:

Gedanken zum x264 CLI ....

Leute - übt mal ein wenig den Umgang mit der Forensuche!
__

Huch, guck - da ist Selur ja schon.

nur so ein hinweis
ich habe ein AMD XP 3200+
ich encode mit den bestmöglichen einstellungen teilelweise mit kompromissen
aber trozdem encode ich bei 720x576 auflösung mit x264 ca. mit 0,40fps
dank der kompatiblilität zum ruhezustand kann man das encoding zum schlafen anhalten
mein 100min film dauert dann so etwa eine arbeitswoche (5tage)

also bedenke dieses wenn du wirklich die beste qualität aben willst

0,4 Frames erscheint mir aber für DVDAuflösung dann doch etwas wenig. Fährst du vorher noch exzessive avisynth skripte?

Poste mal deine Einstellungen.

hier ist mein 3-pass x264 script
da ich 'set' kommands verwende um einzelne werte für verschedene filme anzupassen, musst du es rekonstruieren...

Zitat

@echo off
echo ******************
echo x264 3-Pass Script
echo ******************
echo.

:set
set X264=D:\Programme\Multimedia\Video\codec\x264\CLI\x264.exe

set PS=pause

rem set QMTX=--cqmfile "D:\Programme\Multimedia\Video\codec\x264\matrix\mp4_guy's_AVC_Low_Bitrate_matrix.cfg"
rem set QMTX=--cqmfile "D:\Programme\Multimedia\Video\codec\x264\matrix\q_matrix_jvt.cfg"
rem set QMTX=--cqmfile "D:\Programme\Multimedia\Video\codec\x264\matrix\eqm_avc_hr.cfg"
rem set QMTX=--cqm "jvt"

set BR=912
set BFS=3
rem set DEBL=--filter 3,3
set mrag=16
set xSAR=64:45
set OUT=264

rem Required AR Custom DAR(PAR) Setting
rem 4:3 PAL 720x576 16:15
rem 4:3 PAL 704x576 11:10
rem 4:3 PAL 480x576 16:10
rem 4:3 PAL 352x288 11:10
rem 16:9 PAL 64:45
rem 4:3 NTSC 8:9
rem 16:9 NTSC 32:27

set ZS=--zones 0,144752,b=1/144753,148237,b=0.5

set Xoptions=--bitrate %BR% --stats "%~dpn1-Xp.log" --keyint 300 --ref 16 --mixed-refs --bframes %BFS% --b-pyramid %DEBL% --subme 7 --b-rdo --weightb --analyse all --8x8dct --b-bias 1 --me esa --merange %mrag% --sar %xSAR% %ZS% %QMTX% --progress --no-psnr --trellis 1

:pass
echo ************************
echo x264: 1st pass... (full)
echo ************************
echo.

%X264% --pass 1 %Xoptions% --output "%~dpn1.h264.1p.%OUT%" %1

%PS%

echo ************************
echo x264: 2ed pass... (full)
echo ************************
echo.

rem %X264% --pass 2 %Xoptions% --output "%~dpn1.h264.2p.%OUT%" %1
rem goto end

%X264% --pass 3 %Xoptions% --output "%~dpn1.h264.2p.%OUT%" %1

%PS%

echo ************************
echo x264: 3ed pass...
echo ************************
echo.

%X264% --pass 3 %Xoptions% --output "%~dpn1.h264.3p.%OUT%" %1

:end
echo *****
echo done.
echo *****
%PS%

Alles anzeigen

vielleicht kann ja jemand die einstellungen erweitern bzw. optimieren

p.s. keyframe würd ich gern auf 300 lassen da es mit 25fps & 30fps glatte sekunden werte ergibt
ich würd ja gern nur für szenenwechsel keyframes nutzen aber dann dauert das spulen zu lange...
natürlich bin ich auch einigermaßen qualitäts-besessen
wenn die geschwindigkeit sich auf 0,5 fps steigern würde dann währe ich voll zufrieden

Zitat von HQ-LQ

keyframe würd ich gern auf 300 lassen da es mit 25fps & 30fps glatte sekunden werte ergibt

300 empfinde ich schon als zu hoch, ich gehe nie über 100. ;D

Hab ichs mir doch gedacht! --me esa ist nicht für den täglichen Gebrauch gedacht, sondern nur zum Testen und Tunen.

Du kannst ohne Probleme --me umh verwenden. Das erbringt gegenüber der vollen Suche sogar manchmal einen kleinen PSNR Vorteil.

Damit solltest du deine Geschwindigkeit um Faktor 5-10 steigern können. Dann kannst du ja ausprobieren, ob trellis 2 dir zusagt - relativ langsam, bringt aber was.

Und dann habe ich noch eine vorweihnachtliche Überraschung (eine zum drauf freuen, denn das dauert noch eine Weile) speziell für die Freunde hoher Qualität und langer Encoding-Sessions:

aku arbeitet an dem absoluten Killer-Patch! Dieses Feature wird x264 zum König von H.264 machen (sach ich jetzt mal so).

Bei der Videokompression wird versucht, möglichst wenig Fehler zu machen und wenig Bitrate zu benötigen. Dazu kann der Encoder verschiedene Entscheidungen treffen:

quantizer des Frames
welche Partitionen verwenden für welchen Block
welche Bewegungsvektoren verwenden
welche Prediction Modes
welcher Frame-typ
...

Instinktiv würde man natürlich denjenigen Modus verwenden, der die wenigsten Fehler verursacht. Doch es kann sein, dass dieser Modus sehr viele Bits braucht, um im bitstream festgehalten zu werden.

Beispiel: Die ME hat einen sehr guten Match für die zeitliche Vorhersage eines Blocks gefunden, aber der Motion Vektor ist sehr lange, braucht deshalb sehr viele Bits, um im Stream abgespeichert zu werden. Alternativ könnte man einen kürzeren und somit bitsparenderern MV verwenden, der zwar etwas mehr Fehler im Bild verursacht, aber die gesparten Bits könnten an anderer Stelle vielleicht lohnender eingesetzt werden.

An dieser Stelle kommt die Rate-Distortion-Optimierung ins Spiel. Es wird nicht nach optimalem Fehler allein gestrebt, sondern die optimale Mischung aus wenig Bitverbrauch und wenig Bildfehlern wird gesucht. Es gibt schon diverse RDOs in x264, z.B. die Modedecision (--sub-me 6 und 7) , die MD für B-Frames (--b-rdo) und Trellis (--trellis).

Trellis versucht, die transformierten Bildblöcke RD optimal zu quantisieren, indem es einige Koeffizienten weglässt oder abrundet. Mathematisch gesehen ist das ein recht kompliziertes Verfahren, aber es funktioniert in XviD und x264 recht gut.

Ok, jetzt zum Punkt.

Ein Problem ist, dass aufeinanderfolgende Frames i.A. nicht unabhängig sind. Da P und B Frames aus anderen Frames vorhergesagt werden, wirken sich Fehler in Quellframes auch auf Fehler in den Zielframes aus.

Beispiel: Ein I-Frame wird sehr hoch quantisiert, hat viele Bildfehler. Um die Qualität in den darauf basierenden Frames nicht noch schlechter werden zu lassen, muss man sehr viele Bits aufwenden. U.U. hätte es sich gelohnt, das I Frame nicht so stark zu quantisieren.

An dieser Problematik setzt das sogenannte Look-Ahead-Trellis an. Es werden mehrere Frames gemeinsam betrachtet und auch ihre Abhängigkeiten untereinander. Dann wird auf Basis dieser Daten jeder einzelne Transformierte Koeffizient so quantisiert, dass das Ergebnis nachher RD optimal ist. In der Praxis wird das durchgeführt, indem eine Matrix aufgestellt wird, die das Originalbild und das Decodierte Bild miteinander verknüpft, damit also MC, Quantisierung und Dequantisierung beschreibt. Anhand dieser Matrix werden dann die Koeffizienten optimiert.

Das Problem ist, dass diese Matrix sehr sehr groß wird. Angenommen 3 720x576 Frames würden zusammen betrachtet. Dann wäre die Matrix 3*576*720x3*576*720 = 1,2 10^6x1,2 10^6 Einträge groß. Auf dieser Matrix müssen dann noch komplexe Operationen ausgeführt werden. In dem Forschungsbericht, der dieses Verfahren beschreibt, wurden als experimentelle Ergebnisse Encodierungszeiten von 2.5 minuten für ein 174 * 144 großes Frame bei drei simultan optimierten Frames genannt. Jedoch wurde ein sehr unoptimierter Aufbau verwendet. Das ist also die Schlechte Nachricht: Es wird sehr sehr sehr langsam sein (wie langsam wirklich weiß man noch nicht, denn die Entwicklung ist noch in einem sehr frühen Stadium).

Die gute Nachricht: Der Nutzen wird gigantisch sein. In dem Paper ist die Rede von +2dB PSNR, das entspricht einer Verringerung der Bildfehler um ungefähr 30 % bei gleicher Bitrate.Mir ist kein Encoder bekannt, der so eine krasse Optimierung durchführt (ok, vielleicht der Procoder im Authoring Modus, der läuft auch Tage, aber was er genau macht, weiß man nicht).

Also könnt ihr euch schon mal auf ein bahnbrechendes weiteres Feature von x264 gefasst machen.:)

Zitat von HQ-LQ

nur so ein hinweis
ich habe ein AMD XP 3200+
ich encode mit den bestmöglichen einstellungen teilelweise mit kompromissen
aber trozdem encode ich bei 720x576 auflösung mit x264 ca. mit 0,40fps
dank der kompatiblilität zum ruhezustand kann man das encoding zum schlafen anhalten
mein 100min film dauert dann so etwa eine arbeitswoche (5tage)

also bedenke dieses wenn du wirklich die beste qualität aben willst

Alles anzeigen

Das streite ich ab. Das geht nur bei völlig überzogenen Einstellung so langsam. Poste mal Deine Kommandlines für den ersten und zweiten pass und wir schlagen Dir was besseres vor :yes:

Zitat von JoeB

Das streite ich ab. Das geht nur bei völlig überzogenen Einstellung so langsam. Poste mal Deine Kommandlines für den ersten und zweiten pass und wir schlagen Dir was besseres vor :yes:

Bereits geschehen, s.o.

--keyint 300 : besser 250 bei pal
--ref 16 : ist ein Hammer. Mehr als 5 würde ich nie nehmen
--mixed-refs : bewirkt bei Bitrates unter 500 eine Qualitätsverbesserung die man sieht
--subme 7 --b-rdo : --subme 6 --b-rdo ist mein Standart. --subme 7 ist experimentell
--me esa : ab einer bitrate von 700 reicht umh. Über 1000 reicht hex. me-umh wurde extra als bessere Alternative ermittelt, gab es nämlich zunächst nicht.
--trellis 1 : bringt was meiner Meinung nach. Ab einer bitrate von 1200 schalte ich es ab.

Sehe ich das richtig, dass Du keinen schnellen ersten pass machst? Willst Du mal Einstellungen für einen schnellen ersten pass testen?

Zitat von nexustheoriginal

Keine Ahnung, ich nehm in letzter Zeit nur noch WinAmps AACv2. Das Problem liegt vielleicht auch in der Beschränkung auf 128kbit/s. Kannst ja mal vergleichen: AAC 128kbit mit ogg 0.40 oder so.

so kannst du audiocodecs nicht vergleichen.

Blindtest, beides auf Stereo. Die algorithmen, die winamp aac2plus intern verwendet sind nicht ganz klar.

jo im script sind alle 3 pass'es aufgefürt
ich sage ja nicht umsonnst das man es rekonstuieren sollte

noch eine frage:
es gibt ein bestimmte einstellung die es seit mpeg4 asp gibt (glaube ich)
der ganz helle & dunkle stellen stärker kopremiert

leider habe ich ein film indem 2 dunkle szenen vorkommt
1# da rudert jemand in der dunkelheit duch den nebel
der nebel sieht dementsprechend bescheiden aus
2# ein typ taucht ins wasser und wirft blasen
da die unterwasser aufnahme zihmlich dunkel ist
sind dementsprechend die blasen auch sehr unschön

so wie kann ich diese einstellung ausschalten?

JoeB:

Zitat von JoeB

--keyint 300 : besser 250 bei pal

Warum? 10 Sekunden ist auch nur eine Faustformel. Ist irgendwo nachgewiesen worden, dass 250 irgendeinen Vorteil gegenüber anderen Werten bietet?

Zitat von JoeB

--ref 16 : ist ein Hammer. Mehr als 5 würde ich nie nehmen
--mixed-refs : bewirkt bei Bitrates unter 500 eine Qualitätsverbesserung die man sieht

Die Verbesserungen durch mehr Referenzen sind ab einer gewissen Anzahl nur noch sehr gering. 16 (oder 15) ist das maximum in x264, aber die Hälfte reicht sicherlich auch dicke.

Zitat von JoeB

--me esa : ab einer bitrate von 700 reicht umh. Über 1000 reicht hex. me-umh wurde extra als bessere Alternative ermittelt, gab es nämlich zunächst nicht.

esa ist immer überflüssig. Es ist fakt, dass esa keinen PSNR Gewinn, sondern eher einen Verlust bewirkt. UMH ist besser und viel schneller. Aber auch der Hex Modus ist ausreichend.

Zitat von JoeB

--trellis 1 : bringt was meiner Meinung nach. Ab einer bitrate von 1200 schalte ich es ab.

Warum schaltest du es ab? Um schneller zu encoden?

HQ-LQ: Die Einstellung die du meinst heißt Lumimasking und die gibt es in XviD, nicht jedoch in x264. Wenn du da feintunen willst, solltest du über Zonen den entsprechenden Szenen mehr Bitrate zuweisen. Sharktooths Build hat einen AQ Patch, der helfen könnte, aber nicht unbedingt muss.

hippoth: mpc = Musepack

Diskussionen über Audiocodecs sind jetzt in diesem Beitrag.

@ Kopernikus

Soweit liegen wir micht auseinander Hier die Unterschiede:
--keyint 300 : besser 250 bei pal : ein zehnfaches der framerate, also 250 bei PAL gilt eigentlich als optimal

--ref 16 : ab 5 sieht man keine Verbesserungen mehr. Macht aber nen Unterschied bei bitrate unter 500

ab einer gewissen bitrate schalte ich trellis ab - eben genau um schneller zu encoden

Hier mal ein Beispiel für einen schnellen ersten pass mit wenig Qualitätsverlusten:
--pass 1 --bitrate %bitrate% --stats "x264.log" --bframes 3 --b-pyramid --subme 1 --weightb --trellis 1 --analyse none --me dia --progress --no-psnr --output NUL %Videofolder%\Film.avs

so das klingt ja alles supper
ich werd dann noch ein bissel rum schrauben
dann nochmal zur abnahme posten...

haT wer noch mehr infos/tipps für mein script?

edit:
für die Abnahme
es hat sich fast nichts verändert
vielleicht kann wer noch meine PAR-liste vervollständigen

'--keyint 300' & '--ref 16' lasse ich so

Zitat

@echo off
echo ******************
echo x264 3-Pass Script
echo ******************
echo.

:set
set X264=D:\Programme\Multimedia\Video\codec\x264\CLI\x264.exe

rem set PS=pause

rem set QMTX=--cqmfile "D:\Programme\Multimedia\Video\codec\x264\matrix\mp4_guy's_AVC_Low_Bitrate_matrix.cfg"
rem set QMTX=--cqmfile "D:\Programme\Multimedia\Video\codec\x264\matrix\q_matrix_jvt.cfg"
rem set QMTX=--cqmfile "D:\Programme\Multimedia\Video\codec\x264\matrix\eqm_avc_hr.cfg"
rem set QMTX=--cqm "jvt"

rem set ME=esa (sehr niedrige bitraten)
set ME=umh

set BR=512
set BFS=3
rem set DEBL=--filter -3,-3
set xSAR=66:60
set OUT=264

rem AR PAR
rem 4:3 PAL 720x576 16:15
rem 4:3 PAL 704x576 11:10
rem 4:3 PAL 480x576 16:10
rem 4:3 PAL 352x576 :
rem 4:3 PAL 352x288 11:10
rem 16:9 PAL 720x576 64:45
rem 4:3 NTSC 720x480 8:9
rem 4:3 NTSC 704x480 10:11
rem 4:3 NTSC 480x480 :
rem 4:3 NTSC 352x480 :
rem 4:3 NTSC 352x240 10:11
rem 16:9 NTSC 720x480 32:27

rem set ZS=--zones 0,144752,b=1/144753,148237,b=0.5

set Xoptions=--bitrate %BR% --stats "%~dpn1-Xp.log" --keyint 300 --ref 16 --mixed-refs --bframes %BFS% --b-pyramid %DEBL% --subme 7 --b-rdo --weightb --analyse all --8x8dct --b-bias 1 --me %ME% --merange 32 --sar %xSAR% %ZS% %QMTX% --progress --no-psnr --trellis 2

:pass
echo ************************
echo x264: 1st pass... (full)
echo ************************
echo.

%X264% --pass 1 %Xoptions% --output "%~dpn1.h264.1p.%OUT%" %1

%PS%

echo ************************
echo x264: 2ed pass... (full)
echo ************************
echo.

rem %X264% --pass 2 %Xoptions% --output "%~dpn1.h264.2p.%OUT%" %1
rem goto end

%X264% --pass 3 %Xoptions% --output "%~dpn1.h264.2p.%OUT%" %1

%PS%

echo ************************
echo x264: 3rd pass...
echo ************************
echo.

%X264% --pass 3 %Xoptions% --output "%~dpn1.h264.3p.%OUT%" %1

:end
echo *****
echo done.
echo *****
%PS%

Alles anzeigen