Gedanken zum x264 CLI ....

Selur

Da ich etwas Zeit&Nerven hatte habe ich mich mit dem x264 CLI beschäftigt.

=> Hab mal ein kleines Mapping von CLI Options zu vfw Option gemacht und darunter die Empfehlungen aus dem Wissenswertes des vfw Frontends dazugeschrieben.

Frame-type options:
Name in der CLI <=> Name im vfw Frontend
1. --keyint <integer> <=> Max IDR-keyframe interval
2. --min-keyint <integer> <=> Min IDR-keyframe interval
3. --scenecut <integer> <=> Scene Cut Threshold
4. --bframes <integer> <=> Max consecutive (B-frames)
5. --no-b-adapt <=> deaktivieren der Adaptive B-Frames
6. --b-bias <integer> <=> Bias (B-Frames)
7. --b-pyramid <=> Use as reference (B-frames)
8. --no-cabac <=> CABAC deaktivieren
9. --ref <integer> <=> Max reference Frames
10.--nf <=> deaktivieren des Deblocking Filters
11.--filter <alpha:beta> <=> Deblocking Filter Strength und Threshold

Empfehlungen:
1. --keyint 250 bei PAL bzw. --keyint 240 bei NTSC Material
2. 25 bei PAL bzw. 24 bei NTSC Material
3. einfach weglassen und so den Standardwert --scenecut 40 nehmen
4. --bframes 3
5. die Option nicht benutzen und so B-Frames als Referenzen zulassen
6. einfach weglassen und so den Standardwert --b-bias 0 nehmen
7. aktivieren mittels: --b-pyramid
8. die Option nicht benutzen und so CABAC verwenden
9. --ref 3 bei DVD Auflösungen und höher,--ref 6 bei 1/2 DVD Auflösung und niedriger
10.die Option nicht benutzen und so den Inloop-Deblocking-Filter verwenden

Ratecontrol:
1. --qp <integer> <=> Single pass - Quantizer, wobei 0 hier einer verludtfreien Kompression entspricht
2. --bitrate <integer> <=> Single pass - Bitrate bzw. Bitrate für den Multipass
3. --crf <integer> <=> Hier wird im Gegensatz zu 1. kein konstanter, sondern ein durchschnittlicher Quantizer angegeben
4. --qpmin <integer> <=> Quality - Min QP
5. --qpmax <integer> <=> Quality - Max QP
6. --qpstep <integer> <=> Quality - Max QP Step
7. --ratetol <float> <=> nur für Single pass encodings interessant, legt fest wie stark die Datenrate vom zielwert abweichen darf (etwa +/- 0.5% pro Punkt)
8. --vbv-maxrate <integer> <=> legt die maximale Datenrate fest (siehe Wissenswertes rund um Xvid)
9. --vbv-bufsize <integer> <=> legt die Video Buffergröße fest (siehe Wissenswertes rund um Xvid)
10. --vbv-init <float> <=> legt fest wieviel des VBVs initial belegt sind (ist mir auch nicht ganz klar ;))
11. --ipratio <float> <=> legt fest wieviel höher die Quantizer eines P-Frames im Vergleich zu den I-Frames seien soll auf die er referenziert
12. --pbratio <float> <=> legt fest wieviel höher die Quantizer eines B-Frames im Vergleich zu den P-Frames seien soll auf die er referenziert
13. --chroma-qp-offset <integer> <=> legt fest um wieviel Quantizerstufen Farbinformationen stärker als Helligkeitsinformationen quantisiert werden sollen
14. --pass <1|2|3> <=> Multi pass - 1st/nth pass
15. --stats <string> <=> Statsfile name
16. --rceq <string> <=> erlaubt einem selber eine Funktion festzulegen, nach der die Flußkontrolle arbeitet
17. --qcomp <float> <=> kleinere Werte geben geben mehr Bits zu einfachen Szenen, höhere Werte geben mehr Bits zu komplexeren Szenen
18. --cplxblur <float> <=> verringert Schwankungen in der Quantizervergabe vor der Curve Compression (keine Ahnung was es genau bewirkt=>kann ja wer mal in den Code gucken )
19. --qblur <float> <=> verringert Schwankungen in der Quantizervergabe nach der Curve Compression (keine Ahnung was es genau bewirkt=>kann ja wer mal in den Code gucken )
20. --zones <zone0>/<zone1>/... <=> Zone Options, wobei jede Zone aus <start frame>,<end frame> und <option> besteht, wobei die Option hier q=<integer> (force QP) oder b=<float> (bitrate multiplier) beinhalten muß

Empfehlungen:
1. --qp 0 wenn man verlustfrei Komprimieren will ansonsten sind --qp 20 und --qp 30 ganz brauchbar
2. --bitrate 1000 und höher sollte man bei DVD Auflösungen schon nehmen, würde empfehlen einen Bitratenklkulator zur Hilfe zu nehmen
3. --crf 20 oder --crf 30 sind ganz brauchbar
4. einfach weglassen und so den Standardwert --qpmin 10 nehmen
5. einfach weglassen und so den Standardwert --qpmax 10 nehmen
6. --qpstep 4 ist der Standardwert, aber gerade bei niedrigen Datenraten kann man hier durchaus auch --qpstep 8 nehmen
7-13. einfach weglassen und so die Standardwerte nehmen, man kann gerade bei 11-13 sicher noch nette Sachen machen, jedoch muß man dafür viele Tests machen um Änderungen hier in ihrer Auswirkung abschätzen zu können
14. Im ersten Durchlauf --pass 1 im zweiten Durchlauf --pass 2
15. --stats x264_stats.log
16. Keine Ahnung was da ein besserer Vorschlag wäre als der Defaultwert => weglassen
17. einfach weglassen und so den Standardwerte nehmen
18&19. Keine Ahnung, da ich nicht weiß wie stark die Werte die Quantizerglättung wirklich beeinflußt => viel testen => weglassen
20. weglassen wenn man sie nicht braucht

Werde demnächst auch noch was zu den Bereichen Analysis, Video Usability Info und Input/Output schreiben wenn ich Zeit&nerven finde.

Würde mich über Meinungen, Verbesserungen usw. freuen. Vorallem im RateControlBereich kann ich nicht wirklich etwas empfehlen, da man bei den meisten Features erstmal einiges rumtesten müßte (2pass Encodes! 1pass reicht hier i.d.R. nicht!) und die Features sich durchaus untereinander beeinflussen.

Cu Selur

JoeB

Hi,

sehr schön gemacht - vielen Dank. Auf den ersten Blick, glaube ich, das das mit ratetol nicht stimmt.

Ich glaube hier gehen Werte > 1. Akupenguin sagt 0-100. Aber Du hast das richtig abgelesen aus der Beschreibung unter -info

Selur

hmm,... müßten man wohl mal antesten.

JoeB

Zitat von Selur

hmm,... müßten man wohl mal antesten.

Meine Standarteinstellung für pass 1 ist "ratetol 2"
Im zweiten pass kommt das nicht zum Einsatz

Selur

2? Okay, ich werd mal oben die Anmerkung "muß hier als Kommazahl zwischen 0.01 und 1.0 angegeben werde" entfernen, aber 2 erscheitn mri ein recht unsinniger Wert, da man dann ja direkt mit konstanter Bitrate encoden könnte.

Cu Selur

Kopernikus

ratetol 2 ist eher das Gegenteil von CBR. Da ist wohl die Quantizerverteilung ähnlich wie bei 2 Pass.

Selur

Okay, kann einer was genaueres zu dem Mapping sagen wie die Verteilung dann aussieht?
(was macht denn dann 100 ?)

=> mal etwas im englischen Forum gelesen => scheint so, als ob Ratetolerance festlegt um wieviel sich Quantizer in aufeinanderfolgenden Frames maximal unterscheiden dürfen. D.h. wenn ein Quantizer nicht durch durch cplxblur und qcomp ien einen Bereich kommt der in noch von ratetol akzeptiert wird er entsprechend angepasst.

Cu Selur

Ps.:weiß jemand wue stark der Einfluß von cplxblur und qblur auf die Quantizerverteilung ist ?

Kopernikus

soweit ich das aus dem Code lese, hat man über das vfw Iterface nicht die möglichkeit rate_tol einzustellen, sondern nur qcomp, bei dem 0 = CBR 1 = konstanter Quantizer.

aku hat die Ratecontrol in diesem Threads recht gut erklärt:

http://forum.doom9.org/showthread.php?t=98386

Ausserdem aus dem doc Verzeichnis von x264:

Zitat

A qualitative overview of x264's ratecontrol methods
By Loren Merritt

x264's ratecontrol is based on libavcodec's, and is mostly empirical. But I can retroactively propose the following theoretical points which underlie most of the algorithms:

You want the movie to be somewhere approaching constant quality. However, constant quality does not mean constant PSNR nor constant QP. Details are less noticeable in high-complexity or high-motion scenes, so you can get away with somewhat higher QP for the same perceived quality.

On the other hand, you get more quality per bit if you spend those bits in scenes where motion compensation works well: A given artifact may stick around several seconds in a low-motion scene, and you only have to fix it in one frame to improve the quality of the whole scene.

Both of the above are correlated with the number of bits it takes to encode a frame at a given QP.

Given one encoding of a frame, we can predict the number of bits needed to encode it at a different QP. This prediction gets less accurate if the QPs are far apart.

The importance of a frame depends on the number of other frames that are predicted from it. Hence I-frames get reduced QP depending on the number and complexity of following inter-frames, disposable B-frames get higher QP than P-frames, and referenced B-frames are between P-frames and disposable B-frames.

The modes:

2-pass:
Given some data about each frame of a 1st pass (e.g. generated by 1pass ABR, below), we try to choose QPs to maximize quality while matching a specified total size. This is separated into 3 parts:

Before starting the 2nd pass, select the relative number of bits to allocate between frames. This pays no attention to the total size of the encode. The default formula, empirically selected to balance between the 1st 2 theoretical points, is "complexity ** 0.6", where complexity is defined to be the bit size of the frame at a constant QP (estimated from the 1st pass).

Scale the results of (1) to fill the requested total size. Optional: Impose VBV limitations. Due to nonlinearities in the frame size predictor and in VBV, this is an iterative process.

Now start encoding. After each frame, update future QPs to compensate for mispredictions in size. If the 2nd pass is consistently off from the predicted size (usually because we use slower compression options than the 1st pass), then we multiply all future frames' qscales by the reciprocal of the error. Additionally, there is a short-term compensation to prevent us from deviating too far from the desired size near the beginning (when we don't have much data for the global compensation) and near the end (when global doesn't have time to react).

1pass, average bitrate:
The goal is the same as in 2pass, but here we don't have the benefit of a previous encode, so all ratecontrol must be done during the encode.

This is the same as in 2pass, except that instead of estimating complexity from a previous encode, we run a fast motion estimation algo over a half-resolution version of the frame, and use the SATD residuals (these are also used in the decision between P- and B-frames). Also, we don't know the size or complexity of the following GOP, so I-frame bonus is based on the past.

We don't know the complexities of future frames, so we can only scale based on the past. The scaling factor is chosen to be the one that would have resulted in the desired bitrate if it had been applied to all frames so far.

Overflow compensation is the same as in 2pass. By tuning the strength of compensation, you can get anywhere from near the quality of 2pass (but unpredictable size, like +- 10%) to reasonably strict filesize but lower quality.

1pass, constant bitrate (VBV compliant):

Same as ABR.

Scaling factor is based on a local average (dependent on VBV buffer size) instead of all past frames.

Overflow compensation is stricter, and has an additional term to hard limit the QPs if the VBV is near empty. Note that no hard limit is done for a full VBV, so CBR may use somewhat less than the requested bitrate. Note also that if a frame violates VBV constraints despite the best efforts of prediction, it is not re-encoded.

1pass, constant ratefactor:

Same as ABR.

The scaling factor is a constant based on the --crf argument.

No overflow compensation is done.

constant quantizer:
QPs are simply based on frame type.

all modes:
H.264 allows each macroblock to have a different QP. x264 does not do so. Ratecontrol returns one QP which is used for the whole frame.

Alles anzeigen

Selur

Hab mal ein paar Sachen zusammen kopiert:

Zitat

qcomp : QP curve compression
Ratecontrol equation : blurCplx^(1-qComp)

if qcomp = 1.00 then quantizer is constant for second pass. Real variable bitrate with constant quality.

if qcomp = 0.00 then bitrate is constant for second pass. Real constant bitrate with variable quality.

defaut value is 0.60 (best value for dev eyes)
best value for metric is in 0.70-0.80 interval

Quelle: http://forum.doom9.org/showpost.php?p=700253&postcount=3

Zitat

... When we set qcomp to be 1.0, the quantisation parameter is a contant, thus the quantisation errors of different pictures are at the same level. In this sense, the quality is constant. On the other hand, if we set qcomp to be 0.6, the quality is said to be constant in terms of human visual perception, although different frames may have different levels of quantisation error due to different QPs.

Quelle: http://forum.doom9.org/showpost.php?p=700398&postcount=7

Zitat

If you set qcomp=0 (i.e. "bitrate variability"), then it tries to make each frame use exactly the same number of bits. It's not quite that precise, but that's its goal.

If you set vbv-maxrate and vbv-bufsize to some nonzero values, then it restricts the average bitrate of a certain number of frames (the number being howevermany can fit in your specified vbv-bufsize (which is specified in kbit)). If vbv-maxrate==bitrate, then it's CBR; otherwise it just restricts the peak bitrate.

You can mix any value of qcomp with the vbv stuff, in which case qcomp controls the local allocation of bits within the averaging window. (As opposed to the non-vbv case, where qcomp distributes bits over the whole movie.)

I think the name "VBV" was taken from MPEG-2 or the like. The H.264 standard calls it "HRD". Theoretically, vbv-maxrate is the rate at which the decoder can read from the medium (DVD, network, etc) and vbv-bufsize is the amount of memory it has available to pre-buffer the incoming stream.

Quelle: http://forum.doom9.org/showpost.php?p=699596&postcount=16

Zitat

Example: you want to encode a movie in 700 MB.

2pass: will get exactly 700 MB, and maximize quality.

1pass ABR, ratetol=inf: will get somewhere between, say, 600 and 800 MB. Whatever filesize it happens to produce, the quality will be almost as good as a 2pass encode of that same size.

1pass ABR, ratetol=1 (or the like): will get very close to 700 MB (e.g. 699-701), but will have lower quality than either of the above.

Quelle: http://forum.doom9.org/showpost.php?p=704099&postcount=23

Zitat

...ratetol is not in any particular units. I tried to make it that a given value of ratetol produced the same %error in filesize independent of movie length, but of course longer movies will tend to average out closer to the target even without enforcing anything.

In practice (see some examples), it looks like ratetol=1 is about +/- .5% bitrate, so ratetol=2 would be about +/- 1%. (This does not, however, scale to very large values of ratetol: it converges asymptotically to some maximum variance depending on the content and other settings. ...

Quelle: http://forum.doom9.org/showpost.php?p=705225&postcount=25

Okay, d.h. dann wohl erstmal folgendes:

1. ratetol ist nur für 1pass ABR interessant
2. ratetol beschreibt wieviel die Datenrate eines Frames von der angestrebten Durchschnittlichen Datenrate abweichen darf. Hierbei wird bedeutet ratetol=inf nicht, dass jedes Frame mit minQP encoded wird, sondern dass nach der initialen Quantizerverteilung-/schätzung keine Anpassung mehr anfällt.

Seht ich das auch so?

Cu Selur

JoeB

@ Selur

Habe nun ratetol aus allen meinen batchfiles gelöscht. Irgendwie habe ich damals als die Funktion rauskam das ganz anders verstanden. Aber MegUI setzt das feature nie ein, Du hast das ganz klasse hergeleitet => JoeB muss da was falsch verstanden haben

Kopernikus

Scheint so zu sein. Also ratetol klein, wenn genaue Zielgröße getroffen werden muss, und groß, wenn es auf ein paar MB nicht ankommt, und man sich einen 2Pass sparen will.

Selur

hab da mal Fragen an Leute die das CLI nutzen:

1. Welche Optionen verwendet x264 wenn ich die optionale Option options weg lasse ?

2. Wenn ich die optionale Option widthxheight verwende, wird der Output dann geresized vor dem Encoden oder wird nur ein Picture Aspect Ratio Flag gesetzt, oder passiert was ganz anderes?

3. Wenn man ein avi öffnet werden dann vfw Decoder oder DirectShow Decoder zum Decoden verwendet? (vermute DirectShow)

4. Wenn ich mkv oder mp4 als output format nehmen, werden dann 'nur' (wenn überhaupt) im Videostream etweillige Aspect Ratio Flags gesetzt oder auch (nur?) im Container?

Cu Selur

Kopernikus

2. Diese Option wird nur verwendet, wenn RAW Daten eingelesen werden. Bei avs/avi Input werden die Bilddimensionen aus dem Input ermittelt.

3. Es werden die Microsoft VfW Routinen verwendet, um auf die avi zugreifen zu können, daher vermute ich, dass auch vfw decoder zum decodieren verwendet werden.

1. Aus dem Code, das meiste sollte selbsterklärend sein:

Code

param->cpu = x264_cpu_detect();
    param->i_threads = 1;


    /* Video properties */
    param->i_csp           = X264_CSP_I420;
    param->i_width         = 0;
    param->i_height        = 0;
    param->vui.i_sar_width = 0;
    param->vui.i_sar_height= 0;
    param->vui.i_overscan  = 0;  /* undef */
    param->vui.i_vidformat = 5;  /* undef */
    param->vui.b_fullrange = 0;  /* off */
    param->vui.i_colorprim = 2;  /* undef */
    param->vui.i_transfer  = 2;  /* undef */
    param->vui.i_colmatrix = 2;  /* undef */
    param->vui.i_chroma_loc= 0;  /* left center */
    param->i_fps_num       = 25;
    param->i_fps_den       = 1;
    param->i_level_idc     = 51; /* as close to "unrestricted" as we can get */


    /* Encoder parameters */
    param->i_frame_reference = 1;
    param->i_keyint_max = 250;
    param->i_keyint_min = 25;
    param->i_bframe = 0;
    param->i_scenecut_threshold = 40;
    param->b_bframe_adaptive = 1;
    param->i_bframe_bias = 0;
    param->b_bframe_pyramid = 0;


    param->b_deblocking_filter = 1;
    param->i_deblocking_filter_alphac0 = 0;
    param->i_deblocking_filter_beta = 0;


    param->b_cabac = 1;
    param->i_cabac_init_idc = 0;


    param->rc.b_cbr = 0;
    param->rc.i_bitrate = 1000;
    param->rc.f_rate_tolerance = 1.0;
    param->rc.i_vbv_max_bitrate = 0;
    param->rc.i_vbv_buffer_size = 0;
    param->rc.f_vbv_buffer_init = 0.9;
    param->rc.i_qp_constant = 26;
    param->rc.i_rf_constant = 0;
    param->rc.i_qp_min = 10;
    param->rc.i_qp_max = 51;
    param->rc.i_qp_step = 4;
    param->rc.f_ip_factor = 1.4;
    param->rc.f_pb_factor = 1.3;


    param->rc.b_stat_write = 0;
    param->rc.psz_stat_out = "x264_2pass.log";
    param->rc.b_stat_read = 0;
    param->rc.psz_stat_in = "x264_2pass.log";
    param->rc.psz_rc_eq = "blurCplx^(1-qComp)";
    param->rc.f_qcompress = 0.6;
    param->rc.f_qblur = 0.5;
    param->rc.f_complexity_blur = 20;
    param->rc.i_zones = 0;


    /* Log */
    param->pf_log = x264_log_default;
    param->p_log_private = NULL;
    param->i_log_level = X264_LOG_INFO;


    /* */
    param->analyse.intra = X264_ANALYSE_I4x4 | X264_ANALYSE_I8x8;
    param->analyse.inter = X264_ANALYSE_I4x4 | X264_ANALYSE_I8x8
                         | X264_ANALYSE_PSUB16x16 | X264_ANALYSE_BSUB16x16;
    param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_TEMPORAL;
    param->analyse.i_me_method = X264_ME_HEX;
    param->analyse.i_me_range = 16;
    param->analyse.i_subpel_refine = 5;
    param->analyse.b_chroma_me = 1;
    param->analyse.i_mv_range = -1; // set from level_idc
    param->analyse.i_chroma_qp_offset = 0;
    param->analyse.b_fast_pskip = 1;
    param->analyse.b_psnr = 1;


    param->i_cqm_preset = X264_CQM_FLAT;
    memset( param->cqm_4iy, 16, 16 );
    memset( param->cqm_4ic, 16, 16 );
    memset( param->cqm_4py, 16, 16 );
    memset( param->cqm_4pc, 16, 16 );
    memset( param->cqm_8iy, 16, 64 );
    memset( param->cqm_8py, 16, 64 );


    param->b_repeat_headers = 1;
    param->b_aud = 0;

Alles anzeigen

Selur

Danke für die Infos

zu 2.: Was passiert den wenn ich da ne andere Auflösung angebe als meien Rawdaten eigentlich haben? Verabschiedet sich x264 dann oder geschehen merkwürdige Dinge?

zu 1.: Seh ich das richtig, dass das ein 1pass cbr Encode mit konstantem Quantizer 26 und maximal einem B-Frame in Folge ist?

Kopernikus

Nein, x264 verabschiedet sich nicht, das Bild wird nur schief und läuft durch, denn es wird die falsche Anzahl Pixel pro Reihe ausgelesen.

Selur

Ok. Danke

Cu Selur

Selur

Hab mal ein bissel was getippt:

Zitat

Was soll das Ganze?
Ich schreibe dieses Dokument um interessierten Usern eine kleine Hilfe analog zu einer 'manpage' für den Umgang mit dem x264 CLI zur Verfügung zu stellen.

Für wen ist es gedacht?
Dieses Dokument ist für Leute gedacht, die das CommandLineInterface kurz CLI von x264 benutzen. Es ist definitiv nicht für Newbies gedacht, d.h. es wird eine gewisse Menge an Vorwissen vorrausgesetzt.

1 Grundstruktur eines x264 Aufrufes:
Ein Aufruf der x264.exe folgt folgender Syntax: x264 [options] -o outfile infile [widthxheight]
Dinge in eckigen Klammern [] sind hierbei als optional zu betrachten. Lässt man sie weg so werden Standardwerte verwendet. Lässt man die Option options weg so würde ein 1pass Encode mit konstantem Quantizer 26 und maximal einem B-Frame in Folge durchgeführt. Andernfalls kann man Einstellungen zum Frame-type, zur Ratecontrol, zur Analyse und zu den Video Usability Info vornehmen, welche in den folgenden Abschnitten behandelt werden. Die optionale Option widthxheight ist nur dann nötig wenn man x264 mit .raw Material füttert. x264 kann ansonsten nicht wissen welche Auflösung das Material hat.

Die zwingend zu setzende Option -o outfile infile legt fest wo x264 die Inputdatei finden kann und wo es was für eine Outputdatei erstellen soll. Als input erwartet x264 einen Pfad zu einer Datei mit der Endung .raw, .avi oder .avs, wobei es bei .raw einen Rohdatenstream im YUV 4:2:0 Farbformat erwartet, .avs ein Avisynthscript (https://localhost/www.avisynth.org) sein muß und ein .avi mit vfw Decodern decodiert werden kann.Um zu checken ob dies gegeben ist kann man einfach gucken ob man die Input Datei z.B. Mit https://localhost/www.VirtualDub.org ohne Probleme öffnen kann. Am besten schreibt man den Pfad zur Input/Output Datei jeweils immer in Anführungszeichen, damit es keine Probleme mit etweiligen Leerzeichen im Pfad oder Dateinamen gibt. Neben der Ausgabe von Rohvideodaten (.264) ermöglicht x264 auch direkt das speichern in einen Matroska (.mkv) oder Mpeg4 (.mp4) Container, welche beide ihre Vor- und Nachteile haben.

So nachdem wir nun den Aufbau der Grundstruktur eines Aufrufes der x264.exe geklärt haben geht es weiter mit den Optionen die man wählen kann.

2 Options
Bei x264 unterteilt man die options in vier Unterkategorien:
1.Frame-Type options
2.Ratecontrol
3.Analysis
4.Video Usability Info
Allgemein gilt zu all den Optionen: Wenn man nicht verstanden hat was eine Option macht und wann es sinnig ist sie anzuwenden sollte man sie nicht aktivieren bzw. die Defautleinstellung ändern.

2.1 Frame-type options
Die hier aufgeführten Optionen beschäftigen sich vorallem damit wann IDR-, I- und B-Frames gesetzt werden und wie sie gespeichert werden.

2.1.1 -I <integer> bzw. --keyint <integer>
Der hier festzulegende Wert gibt an, nach wievielen Frames spätestens ein IDR-Frame gesetzt werden soll. Einerseits ist es aus kompressionstechnischen Gründen sinnvoll, diese nur an Szenenwechseln zu setzen, andererseits kann man nur von einem zum nächsten IDR-Frame springen und bei diesen schneiden, da man sonst nicht sicher wüsste, dass man keine Frames entfernt, auf die vielleicht später noch referenziert wird. Man will also nicht zu wenige, da man sonst nur in groben Sprüngen im Film umherspulen bzw. -springen oder nur sehr 'ungenau' schneiden kann. Als guter Richtwert erscheint mir ein Wert, der etwa dem zehnfachen der Framerate entspricht. Für PAL-Filme wäre dies ein Wert von 250. (NTSC = 240 bzw. 300)
Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 250.

Sollte normalerweise weglassen wenn man PAL-Material verwendet, bei NTSC-Material sollte -I 300 gewählt werden.

2.1.2 -i <integer> bzw. --min-keyint <integer>
Hier legt man eine Grenze für den minimalen Abstand zwischen zwei IDR-Frames fest. Da man nur an IDR-Frames schneiden kann, will man keine zu große Distanz. Ein Wert von 1 sort dafür, dass der Codec jedes I-Frame automatisch zu einem IDR-Frame machen. Dieses vom Programmierer festgelegte verhalten würde x264 um die Möglichkeit multipler Referenzframes über mehrere I-Frames hinweg berauben würde. Allgemein wird von den Programmierern ein Interval von 0.4*Max IDR-keyframe interval empfohlen. Unter einen Mindestabstand, der der Framerate entspricht sollte man möglichst nicht gehen, da die Heuristik zur Entscheidung ob ein IDR-Frame gesetzt wird oder nicht anscheinend noch nicht ganz ausgereift ist. Persönlich wähle ich immer den Mindestabstand. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 25.

Sollte normalerweise weglassen werden wenn man PAL-Material verwendet, bei NTSC-Material sollte -i 30 gewählt werden.

2.1.3 --scenecut <integer>
Dieser Schwellenwert legt fest ab wieviel Prozent an Bildänderung ein neues Bild als Szenenwechsel erkannt wird, was direkt beeinflusst ob ein I-Frame gesetzt wird oder nicht. Das Problem ist, dass I-Frames idealerweise immer bei stärkeren Änderungen als qualitativhochwertige Referenzframes gebraucht werden, sie jedoch einiges mehr an Datenrate benötigen als P- und B-Frames und deshalb nich unnötig oft verwendet werden sollten. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 40.

Sollte normalerweise weglassen werden.

2.1.4 -b <integer> bzw. --bframes <integer>
Dieser Parameter legt fest, wie viele B-Frames (Bidirektionale Frames) hintereinander erlaubt sind. Durch die Möglichkeit der Bidirektionalenreferenz können B-Frames vor allem im mittleren und unteren Datenratenbereich (bei DVD Sicherheitskopien so kleiner 1500kBit/s) einiges an Datenrateneinsparungen bringen, ohne zu sichtbaren Qualitätsverlusten zu führen. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 0, was die Nutzung von B-Frames deaktiviert. Zu beachten ist, dass man hier nur eine obere Schranke festlegt, bei normalem Videomaterial werden aber nur seltenst mehr als fünf B-Frames in Folge benötigt. Würden mehr verwendet wäre ein zugroßer Detailverlust zu befürchten.

Sollte normalerweise zwischen -b 3 und -b 5 gewählt werden.
2.1.5 –no-b-adapt
Dieser Parameter ermöglicht es einem die an das Quellmaterial angepasste B-Frame-Auswahl zudeaktivieren, was zwar etwas an Performance bringt, jedoch in Hinsicht auf die Qualität in der Regel nicht zu empfehlen ist, besonders wenn man Werte größer Eins bei der maximalen Anzahl von auseinanderfolgenden B-Frames gewählt hat.

Sollte normalerweise weglassen werden.
2.1.6 --b-bias <integer>
Mit diesem Parameter kann der User die prozentuale Wahrscheinlichkeit erhöhen/senken, dass anstatt einem P- ein B-Frame verwendet wird. Das mit -b <integer> festgelegte Maximum wird hierdurch jedoch nicht überschritten. Es ist vielmehr die Frage, wie schnell bzw. ob es erreicht werden wird. Erhöht man die Wahrscheinlichkeit wird mehr Datenrate gespart, jedoch kann es zu einem verstärkten glätten des Bildes kommen. Senkt man die Wahrscheinlichkeit werden seltener B-Frames verwendet, jedoch kann dies dazu führen, dass das man etwaiges Deblocking verstärken muss damit keine Makroblöcke sichtbar werden. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 0. Meiner Erfahrung nach macht es nur bei extrem niedrigen Auflösungen und in Vor- und Abspännen Sinn dies Feature zu benutzen und den Standardwert zu verändern.

Sollte normalerweise weglassen werden.

2.1.7 --b-pyramid
Erst wenn man dieses Feature aktiviert können B-Frames auch wieder auf B-Frames referenzieren, was nochmal einen kleinen Qualitätsgewinn bringt, jedoch auch die CPU Anforderung leicht steigert. Außer vielleicht wenn man für Handys&Co encoded würde ich dieses Feature immer aktivieren.
Sollte normalerweise mit --b-pyramid aktiviert werden.

2.1.8 --no-cabac
x264 unterstützt dabei neben CAVLC (Context Adaptive Variable Length Coding), einer Huffman-artigen, auch eine leistungsfähigere arithmetische Codierung namens CABAC (Context Adaptive Binary Arithmetic Coding). Da eine Beschreibung von CABAC bzw. arithmetischer Codierung die meisten Leser eh nur langweilen würde, möchte ich hier auf einen netten und kurzen 'Artikel' hinweisen, den man unter http://www.computerbase.de/lexikon/Arithmetisches_Kodieren finden und lesen kann. Ich persönlich finde, CABAC ist das beieindruckendste Feature bei x264, was die dahinterstehende Technik/Idee betrifft.Was für alle Leser aber interessant ist, ist, dass CABAC relativ langsam ist, aber ca. 10% an Datenrateneinsparungen bringt, und deshalb definitv aktiviert werden sollte. Nur wenn man x264 zum Capturen benutzt, sollte man eventuell mit der Option –no-cabac von CABAC Abstand nehmen.

Sollte normalerweise weglassen werden.

2.1.9 -r <integer> bzw. --ref <integer>
Anders als bei anderen MPEG-Varianten können sind bei H.264 auch multiple Referenzframes, zu einem Frame möglich. Mit diesem Parameter legt fest wieviele andere Bilder auf der Suche nach Ähnlichkeiten durchsucht werden und als Referenzen dienen können. Bei Auflösungen die größer oder gleich der Auflösung einer DVD sind sollte man hier nicht mehr als 5 nehmen, da man sonst nur seltenst noch eine Verbesserung erziehlt jedoch einiges mehr an Zeit beim Komprimieren benötigt. Bei sehr niedrigen Auflösungen, etwa 320x240 und kleiner, kann man hier aber durchaus auch Werte bis 16 nehmen.Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 1.
Sollte normalerweise -r 6 sein.

2.1.10 --nf
Mit dieser Option kann der Loop-Filter von x264 deaktiviert werden. Die Aufgabe des Loopfilters ist es an den Grenzen der Blöcke in die ein Bild eingeteilt wird zu glätten, so dass auch bei hohen Quantizern das Bild eher verschwommen als artefaktartig wirkt. Meiner Erfahrung nach sollte man den Loopfilter nur dann deaktivieren, wenn man definitiv nicht genug Prozessorpower hat.

Sollte normalerweise weglassen werden.

2.1.11 -f <integer:integer> bzw. --filter <integer:integer>
Mit diesen Parametern kann man den Inloop-Deblocking-Filter von x264 beeinflußen, der dafür sorgt, dass auch bei starker Kompression möglichst keine Makroblockübergänge zu sehen sind, wie es bei anderen MPEG-Varianten der Fall ist. Grob gesagt wird einfach an den Makroblockübergängen geglättet. Der erste Wert legt die Stärke der Glättung fest und der zweite Wert legt fest, ab wann geglättet wird. Je nach Zielgröße sollte man die Stärke und den Schwellenwert etwas verändern. Persönlich lasse ich bei 1-CD-Sicherheitskopien einer DVD beideWerte auf 0 und stelle bei 2 CDs oder mehr die Stärke auf -2. Gerade bei kleinen Clips oder verrauschtem Inputmaterial sollte man aber am Besten erst etwas herumprobieren, um nicht zu viel oder zu wenig zu glätten. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 0:0.
Sollte normalerweise weglassen werden.

2.2 Ratecontrol
Bei den folgenden Optionen geht es darum die Datenratenverteilung von x264 zu beeinflußen und zu entscheiden mit welcher generellen Vorgehensweise das Material encoded wird.

2.2.1 -q <integer> bzw. --qp <integer>
Dieser Parameter ist nur interessant wenn man einen Single Pass Encode machen will mit einem festen Quantizer. Ein Quantizer von 0 würde hierbei einer verlustfreien Kompression entsprechen.

Sollte nur verwenden wenn man einen single pass constant quantizer encode machen will.

2.2.2 -B <integer> bzw. --bitrate <integer>
Dieser Parameter ist nur interessant wenn man einen Single Pass Encode machen will mit einer angestrebten durchschnittlichen Datenrate. Durchschnittlich ist hierbei der wichtige Punkt. Auf jeden Fall gibt man hier dir Datenrate in Bit und nicht wie in vielen anderen Programmen in Kilobit an.
Sollte nur verwenden wenn man einen single pass average bitrate encode machen will.

2.2.3 --crf <integer>
Dieser Parameter ist nur interessant wenn man einen Single Pass Encode machen will mit einer angestrebten durchschnittlichen Quantizer. Durchschnittlich ist hierbei der wichtige Punkt.

Sollte nur verwenden wenn man einen single pass average quantizer encode machen will.

2.2.4 --qpmin <integer>
Dieser Parameter legt eine untere Schranke für den kleinsten Quantizer fest der beim single pass abr oder multipass Encoden benutzt werden darf. Persönlich setze ich diesen Wert meist auf 0, beim Encoden von normalem DVD/DVB Material mit einer Datenrate von 1000 - 2000kBit/s kann man den Wert jedoch beruhigt auf 10 setzen, da niedrigere Quantizer eh nicht vorkommen werden und man so dem Encoder etwas unter die Arme greift.Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 10.

Sollte normalerweise weglassen werden.

2.2.5 --qpmax <integer>
Dieser Parameter legt eine obere Schranke für den größten Quantizer fest der beim single pass abr oder multipass Encoden benutzt werden darf. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 51. Bei normalen DVD/DVB&Co Encodes kann man ihn aber ruhig auf 42 senken.

Kann man ruhig mit --qpmax 42 aufrufen.
2.2.5 --qpstep <integer>
Dieser Parameter legt fest wie stark die Quantizerschwankung zwischen zwei benachbarten Frames seien darf die beim single pass abr oder multipass Encoden auftreten darf.. Ein zu niedriger Wert führt dazu, dass die Ratecontrol keinen Spielraum hat und man einen Constant Quantizer Encode erhält und ein zu hoher Wert führt eventuell dazu, dass man enorme Qualitätsschwankungen erhält. Für DVD Auflösungen ist vier normalerweise okay, für sehr kleine Auflösungen ist acht aber öfters besser.Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 4.
Sollte normalerweise weglassen werden.

2.2.6 --ratetol <float>
Dieser Parameter ist nur interessant wenn man einen Single Pass Encode machen will mit einer angestrebten durchschnittlichen Datenrate. ratetol beschreibt wieviel die Datenrate eines Frames von der angestrebten Durchschnittlichen Datenrate abweichen darf (etwa +/- 0.5% pro Punkt). Hierbei wird bedeutet ratetol=inf nicht, dass jedes Frame mit minQP encoded wird, sondern dass nach der initialen Quantizerverteilung-/schätzung keine Anpassung mehr anfällt. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 1.0.

Sollte normalerweise weglassen werden.

2.2.7 --vbv-maxrate <integer>
Mit diesem Wert kann man die maximale Datenrate festlegen. VBV steht für 'Video Buffering Verifier'. Interessant ist dieser Parameter normalerweise nur wenn man für bestimmte Geräte encoded die nur Clips bis zu einer gewissen Datenrate encoden können. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 0, was eine beliebig hohe Datenrate zulässt.

Sollte normalerweise weglassen werden.

2.2.7 --vbv-bufsize <integer>
Mit diesem Wert kann man die maximale Buffergröße festlegen, die ein Geräte zur Verfügung stehen muß, das den Strem später einwandfrei decoden kann. Interessant ist dieser Parameter normalerweise nur wenn man für bestimmte Geräte encoded die nur eine forgegebene Buffergröße besitzen. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 0, was besagt, dass x264 nicht garantiert, dass eine bestimmte Buffergröße ausreichend ist um den encodeten Stream abspielen zu können.

Sollte normalerweise weglassen werden.

2.2.8 --vbv-init <float>
Dieser Wert legt fest wieviel des Video Buffers eines Endgerätes initial belegt werden ehe die Wiedergabe gestartet wird. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 0.0, d.h. es würde einfach mit dem Playback gestartet und davon ausgegangen, daß der Video Buffer nicht nötig bzw. immer ausreichend gefüllt ist.

Sollte normalerweise weglassen werden.

2.2.9 --ipratio <float>
Mit diesem Parameter legt man fest wieviel höher die Quantizer eines P-Frames im Vergleich zu den I-Frames seien soll auf die er referenziert. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 1.4, d.h. P-Frames werden immer mit mindestens einem 40% größeren Quantizer encoded, als dass I-Frame auf das sie verweisen.

Sollte normalerweise weglassen werden.

2.2.10 --pbratio <float>
Mit diesem Parameter legt man fest wieviel höher die Quantizer eines B-Frames im Vergleich zu den P-Frames seien soll auf die es referenziert. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 1.3, d.h. B-Frames werden immer mit mindestens einem 30% größeren Quantizer encoded, als dass die P-Frames auf das sie verweisen.

Sollte normalerweise weglassen werden.

2.2.11 --chroma-qp-offset <integer>
Mit diesem Parameter legt man fest um wieviel Quantizerstufen Farbinformationen stärker als Helligkeitsinformationen quantisiert werden sollen. Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 0. Je nach Film kann hierdurch sicher einiges eingespart werden, ich würde jedoch normalerweise davon abraten einen der Bereiche Stärker zu quantizieren.

Sollte normalerweise weglassen werden.

2.2.12 --pass <1|2|3>
Hat man sich entschieden anstatt einem one pass ein multi pass encoding durchzuführen, so teilt man mit diesem Parameter dem Encoder mit in welchem pass er sich befindet. Normalerweise sollte man hier nur --pass 1 und --pass 3 verwenden,da --pass 2 das gleiche wie --pass 3 macht, nur das kein Analysefile mehr erstellt wird. Außer bei sehr kurzen Clips lohnt es sich aber nur seltenst mehr als zwei Duchgänge (pass 1 + pass 3) durchzuführen.

Sollte normalerweise erst einmal mit --pass 1 und dann beliebig oft mit --pass 3 aufgerufen werden..

2.2.12 --stats <string>
Hiermit kann man festlegen wo in jedem Encodingdurchlauf die etweilige Statistikdatei erstellt werden soll. Achtung, die Datei wird nach jedem Durchlauf durch eine neue ersetzt.Lässt mand en Parameter weg, so legt x264 automatisch eine Datei namens x264.stats im Hauptverzeichnis des Datenträgers des Inputfiles an.

Sollte normalerweise weglassen werden.

2.2.13 --rceq <string>
Über diesen Parameter kann der User die Formel ändern über die x264 die Datenratenflußkontrolle regelt. Der Standartwert den x264 nimmt, wenn man den Parameter weglässt ist "blurCplx^(1-qComp)". Eventuell gibt es hier besser geeignete Formeln, jedoch bis jemand eine findet würde ich raten die Finger von diesem Parameter zu lassen.

Sollte normalerweise weglassen werden.

2.2.14 --qcomp <float>
Mit diesem Wert kann man grob festlegen was im jedem Multipass eher angestrebt wird. Eine konstante Qualität, d.h. jedes Bild verliert gleichmäßig viele Informationen oder eher eine konstante Datenrate, d.h. jedes Bild wird mit der gleichen Menge an Bits kodiert egal wie komplex es ist. Eim Wert von 1 würde hierbei zu einem konstantem Quanizer encode und eine Wert von 0 zu einem konstanten Bitraten Encode führen. Der Standartwert den x264 nimmt, wenn man den Parameter weglässt ist 0.6, da die Entwickler diesen Wert am Optisch ansprechensten in den Ergebnissen fanden. Metriken, wie PSNR liefern jedoch mit Werten im bereich 0.7 bis 0.8 meist bessere Werte.

Sollte normalerweise weglassen werden.

2.2.15 --cplxblur <float>
So wie cplxblut momentan in der Formel für die Datenratenflußkontrolle verwendet wird, verringert es Schwankungen in der Quantizervergabe vor der Curve Compression.Verändert man die Formel für die Datenratenflußkontrolle sollte man eventuell auch hier etwas ändern. Der Standartwert den x264 nimmt, wenn man den Parameter weglässt ist 20.0.

Sollte normalerweise weglassen werden.
2.2.16 –qblur <float>
Dieser Parameter ist für eine Reduzierung der Schwankungen in der Quantizervergabe nach der Curve Compression zustaändig. Der Standartwert den x264 nimmt, wenn man den Parameter weglässt ist 0.5.

Sollte normalerweise weglassen werden.

Anmerkung:Wer einen groben Überblick darüber braucht wie die Ratecontrol in x264 funktioniert sollte sich eventuell mal dieses (https://trac.videolan.org/x264/changeset/350?format=diff) Dokument angucken.

Alles anzeigen

So, mehr gibt's erst demnächst, wobei ich mich schon über Feeedback und Verbesserungen freuen würde. Da muß sicher einiges noch umgeschrieben werden.

Cu Selur

Kopernikus

zu 1

vielleicht ein Beispiel
Hinweis, dass avs (mkv/mp4) support miteincompiliert sein muss.

zu 2.1.4

"Der Standardwert den x264 nimmt wenn man den Parameter weglässt ist 0"

Ich dachte 1?

zu 2.1.9

das maximum an Referenzen ist 16

zu 2.1.10

weglassen des Loopfilters bei sehr hohen Datenraten?

Ich denke man sollte noch die Möglichkeit erwähnen mit --ratetol inf einen 1Pass mit 2Pass ähnlicher Quantizerverteilung zu erzielen.

Sonst schon sehr ansprechend

Selur

zu 1: werd anmerken, dass ich mich auf die Version beziehe die von shaarktooth kommt
zu 2.1.4: Sicher? Wenn man die x264.exe aufruft sagt die 0.
zu 2.1.9: werd ich anmerken
zu 2.1.10: Wenn man nah an Lossless kommt, halte ich Loopfilter irgendwie für kontraproduktiv.

Zitat

Ich denke man sollte noch die Möglichkeit erwähnen mit --ratetol inf einen 1Pass mit 2Pass ähnlicher Quantizerverteilung zu erzielen.

wird gemacht

Zitat

Sonst schon sehr ansprechend

*freu* zumindest für den ersten Entwurf soweit
Bin noch am Überlegen ob ich das ganez später als pdf mit Formatierung&Cod oder einfach als txt veröffentlichen soll.
(Hat da wer vorlieben?)

Cu Selur

Kopernikus

Also ich finde, so ein suaber getextes PDF hat mehr Stil als eine txt Datei.

Zu 2.10

Soweit ich weiß, wird der Loopfilter bei Q<15 oder so sowieso automatisch deaktiviert, von dem her hast du recht. Bei q=0 ist er laut standard deaktiviert.

Jetzt mitmachen!