MeGUI/x264 Settings

x264 Settings

Frame-type options

keyint

Integer: 250

Sets the maximum interval between IDR-frames (aka keyframes) in x264's output. Normally, x264 will only make a frame an IDR frame if it passes the threshold set by scenecut. This setting lets you place an upper bound on length of time before an IDR frame appears. IDR frames are 'delimiters' in the stream - no frame can reference data from the other side of the IDR. These mean they can be used as points to randomly seek in the movie (you can't just start playback from anywhere, the frame will reference previous frames, and they will reference previous frames, and etc). Note that while an IDR frame is necessarily an I frame, not all I frames are IDR frames. Most of the time x264 will make the first frame of a new camera scene an IDR frame, so much of the time this setting will not come into play. Higher settings can theoretically improve compression (reducing the number of forced IDR frames which would otherwise be smaller P or B frames), as well as reducing the appearance of fluctuating quality if the average quantizers are high (since I frames share no similarity in terms of artifacts with their neighbours the artifacts are more noticeable). Lower settings can reduce the time needed to seek to a certain frame.

Recommendation: Default, or 10x whatever your framerate is. On HD encodes which will be CPU challenging you may want to use smaller values (say 2x - 5x fps).

See also: min-keyint, scenecut

min-keyint

Integer: 25

Sets the minimum length between IDR frames. See keyint for an explanation of IDR frames. Very small IDR ranges can reduce 'incorrect' frame placement (for example, a strobing scene). This option limits the minimum length after each IDR frame before another can be placed.

Recommendation: Default, or whatever your framerate is.

See also: keyint, scenecut

scenecut

Integer: 40

Sets the threshold for IDR frame placement (read: scene change detection). x264 calculates a metric for every frame to estimate how different it is from the previous frame. If the value is lower than scenecut, an IDR frame is used. The metric is slightly more complex then, but it's a reasonable approximation. Higher values of scenecut increase the number of scenecuts detected. For more information on how the scenecut comparison works, see this doom9 thread.

See also: keyint, min-keyint, pre-scenecut

pre-scenecut

Default: disabled when --threads 1, else enabled

Enables a faster scenecut mechanism. It's enabled by default when you use more than one thread, since regular (not pre) scenecut doesn't work with threads. Normal IDR frame encoding works by encoding the frame normally, then if the frame passes the scenecut test, re-encoding it as an IDR frame. Pre-scenecut detects before encoding if the frame should be an IDR frame and acts accordingly. Pre-scenecut is theoretically not as good as normal scenecut, although the cost of this is usually low. See this doom9 thread for more information about the quality loss from bad IDR frame placement.

Recommendation: Default

See also: keyint, min-keyint, scenecut, threads

bframes

Integer: 0

Sets the maximum number of concurrent B-frames that x264 can use. B-frames are similar to P-frames, except they can use motion prediction from future frames as well. This can lead to significantly better efficiency in terms of compression ratio. Their average quality is controlled by pbratio. For more information about the choices x264 makes between P or B frames for each candidate frame, see this ffmpeg-devel mail. In this case, frame types will look like this (in display order) (assuming --bframes 3): IBBBPBBBPBPI.

Bonus info: x264 also occasionally distinguishes between two different sorts of B-frames. A 'B' can refer to a B-frame that is used as a reference by other frames, while 'b' can refer to a B-frame that is not. If you see a mix of 'B' and 'b', it's usually related to the above. When the difference is not important, just 'B' is generally used to refer to all B-frames.

Recommendation: Unless you use --b-adapt 2 choose --bframes 16, the maximum. This is the fastest and most flexible option for the encoder. If you use --b-adapt 2 much lower --bframes is reasonable, like 2-5. Higher values will significantly slow the encoding without major benefit. For an idea of how many B-frames are used in your encode, read the "consecutive B-frames" line in x264's stats output after an encode.

Sometimes you'll have to settle for less: Blu-Ray limits the maximum number of B-frames.

B-frames also may increase decoder CPU usage, but the reduced bitrate (and thus reduced time spent on CABAC) may counteract that. Any effect would be minor.

See also: no-b-adapt, b-bias, b-pyramid, ref, pbratio, partitions, weightb, b-rdo, bime

no-b-adapt

Note: this option is for backward compatibility, use b-adapt 0 instead.

Default: Not Set

Disables adaptive B-frame placement. Normally, when encoding a length of frames, x264 will encode some as B and some as P frames, in a mix which is most efficient. This may mean no B frames are used for a number of frames. Setting this option removes the adaptive decision making and forces x264 to use as many B frames as it can.

Example: you run an encode with 3 max B-frames, and with b-adapt enabled (ie the default). You see this (in display order): IBBPPBBBPBBPBPBPI. If you run it again with no-b-adapt you'll see this: IBBBPBBBPBBBPBBPI. Note that the sequence is simply interrupted for the final group of three at the end of the GOP. There's no real advantage to this setting, the disadvantage is that you reduce the efficiency of x264. You'll end up with non-optimal frame type decisions. Note that if you want to force a specific number of B-frames in threaded mode, scenecut must also be disabled, by setting it to -1: this is because pre-scenecut does not work with no-b-adapt.

Recommendation: Default, see above.

See also: b-frames

b-adapt

Note: For a multi-pass encode, this option is only needed for the first pass where frame types are decided.

0 - disable

1 - old algorithm, faster, speed slightly increases with higher b-frames setting.

2 - new algorithm, slower, speed significantly decreases with higher b-frames setting.

b-bias

Integer: 0

Controls the likelihood of B-frames being used instead of P-frames. Values great than 0 increase the weighting towards B-frames, while values less than 0 do the opposite. This number is no a percentage, or absolute increase, just an arbitrary metric number. The range is from -100 to 100. Note that a value of 100 does not guarantee every P-frame will be converted (use no-b-adapt for that).

Only use this if you think you make better ratecontrol decisions than x264.

Recommendation: 0

See also: b-frames, See also: ipratio

b-pyramid

Default: Not set

Allow the use of B-frames as references for other frames. Without this setting, frames can only reference I or P-frames. Although I/P-frames are more valued as references because of their higher quality, B-frames can also be useful. B-frames designated as references will get a quantizer halfway between P-frames and normal B-frames.

Recommendation: Enabled, if you have at least two B-frames. Slows encoding slightly. Note: in older x264 revisions this increased DPB size, but this is now constant based on ref.

See also: b-frames, refs, mixed-refs

no-cabac

Default: Not set

Disables CABAC (Context Adaptive Binary Arithmetic Coder) stream compression and falls back to the less efficient CAVLC (Context Adaptive Variable Length Coder) system. Significantly reduces both the compression efficiency and the decoding requirements.

Many handheld devices don't have the processing power to play back CABAC content, so you need to encode CAVLC for them. Stuff produced by Apple Computers also tends to lack the ability to decode CABAC properly. The benefit of CABAC is about 10-20% compression over CAVLC.

Recommendation: Disable only if your player doesn't support it.

ref

Default: 1

Controls the size of the DPB (Decoded Picture Buffer). The range is from 0..16. In short, this value is the number of previous frames each P-frame can use as references. B-frames can use one or two fewer, depending on if they are used as references or not. The minimum number of refs that can be referenced is 1.

Note, this setting used to control the number of refs used. See this doom9 post outlining the difference.

Also note that the ITU-T specification limits DPB and thus limit the ref for each level. If adhering to Level 4.1 specs, the maximum ref for full height 720p and 1080p video are 9 and 4 respectively. But if the video's height is not the full 720 or 1080 pixels, a higher ref can be used. Level 4.1 is the level implemented on Blu-ray and HD DVD, and the highest level supported in most consumer electronics which support H.264 playback, including Xbox 360, Playstation 3 and Popcorn Hour A-100 Media Extender. The formula for calculating maximum ref is as follows, the value should be rounded down:

maximum ref = 12288 * 1024 / ( width * height * 1.5)

Recommendation: Around 4-6. Each increase has a reduced benefit and constant speed loss. Very large numbers of refs are normally not very useful, but even up to 16 can be helpful for animated content, video game capture, CGI, and other similar content.

See also: b-pyramid, mixed-refs, level

no-deblock

Completely disables in-loop deblocking.

See Also: deblock

deblock

Default: 0:0

Controls the loop filter (aka inloop deblocker) which is part of the h264 standard. The loop filter takes a rather large slice of decoding time for a single item, and is responsible for a similar slice of the overall quality output. It is very efficient in terms of encoding time vs. quality gained.

You can find a good description of how the loop filter parameters work in this doom9 thread (see the initial post and akupenguin's replies).

Recommendation: Default. Lower values can be used if you feel x264 is blurring too much, although this only helps if you have enough spare bitrate. Sane values are probably within the range -3 to 3. Note that at higher bitrates (and thus lower quantizers), deblocking is inherently weaker, so you do not need to "compensate" for higher bitrate with lower deblocking settings or vice versa.

See Also: yes-deblock1 -3 -3

interlaced

Default: Not Set

Enable interlaced encoding. x264's interlaced encoding is inherently less efficient than its progressive encoding, so it is probably better to deinterlace an interlaced source before encoding rather than use interlaced mode.

Ratecontrol

qp

Default: Not Set

The first of three possible ratecontrol methods. Set x264 to encode the movie in Constant Quantizer mode. The number you give here specifies the P frame quantizer. The quantizer used for I and B-frames is derived from ipratio and pbratio. CQ mode targets a certain quantizer, which means final filesize is not known (although it can be reasonably accurately estimated with some methods). A setting of 0 will produce lossless output. qp produces larger files than crf for the same visual quality. qp mode also disables adaptive quantization, since by definition "constant quantizer" implies no adaptive quantization.

This option is mutually exclusive with bitrate and crf. See this writeup for more information on the various ratecontrol systems.

Recommendation: Use crf instead

See also: bitrate, crf, ipratio, pbratio

bitrate

Default: Not Set

The second of three ratecontrol methods. Encode the video in target bitrate mode. x264 will attempt to encode the video to target the given bitrate as the final average. The parameter given is the bitrate in kilobits/sec. (8bits = 1byte and so on). This setting is usually used in conjunction with pass for two pass encoding. Target bitrate mode means the final filesize is known, but the final quality is not (although it's possible to estimate with a reasonable degree of accuracy). It is generally not recommended to use bitrate mode without 2pass encoding.

This options is mutually exclusive with cq and crf. See this writeup for more information on the various ratecontrol systems.

Recommendation: Something which gives P frame quantizers around 18-26. Estimated ranges: for SD resolution: 800kbits - 2100kbits. For 720p, 3-6mbit. For 1080p, 8-15mbit+.

See also: qp, crf, ratetol, pass, stats

crf

Default: 23

The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain 'quality'. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. It is not extremely exact, but reasonably close (and will average out to be accurate over a large number of videos).

CRF achieves this by reducing the quality of less important frames. In this case, frames in complex or high-motion scenes, where quality is more expensive (in terms of bits) and/or less visible, will have their quantizer increased. The bits saved in cuts like this are redistributed to frames where they will be more effective. CRF mode gives almost exactly equivalent quality to 2pass at the same bitrate; the difference is that you cannot choose the output bitrate.

This option is mutually exclusive with cq and bitrate. See this writeup for more information on the various ratecontrol systems.

Recommendation: The range 18-26 is probably where you will want to look at. If you need absolutely perfect quality you could go down to 16, but it's probably not worth it. Around 19-21.5 is where a rip will look very good. Higher res encoding can generally get away with higher crf values.

See also: qp, bitrate

vbv-maxrate

Default: 0

Sets the maximum bitrate in VBV mode. You should only use VBV if you have a hardware decoder that requires it. It is highly recommended, though not required, to use 2pass bitrate mode with VBV.

See also: vbv-bufsize, vbv-init

vbv-bufsize

Default: 0

Sets the maximum size of the VBV buffer. You should only use VBV if you have a hardware decoder that requires it. The buffer chosen is generally specific to the target device.

See also: vbv-maxsize, vbv-init

vbv-init

Default: 0

Sets the initial size of the VBV filled buffer size. Shouldn't be adjusted.

See also: vbv-maxsize, vbv-bufsize

qpmin

Default: 10

Defines the minimum quantizer that x264 will ever use. The lower the quantizer, the closer the output is to the input. At some point, the output of x264 will look the same as the input, even though it is not exactly the same. Usually there is no reason to allow x264 to spend more bits than this on any particular frame / area. For most videos, anything below q16 will be perceptually lossless in this way, and anything below the conservative default of q10 will certainly be.

You can use this setting to prevent creating needlessly oversized files. Take note if you set this aggressively (ie to 16 or such), and your bitrate based encode is not coming out as large as it should be, this is possibly the reason why. You should analyse x264's stats output at the end of encoding and see if all frames are being at the minimum quantizer.

With adaptive quantization enabled (on by default), raising qpmin beyond its default is strongly discouraged because this could reduce the quality of flat background areas of the frame.

See also: qpmax, ipratio.

qpmax

Default: 51

The opposite of qpmin above. Defines the maximum quantizer that x264 can use. The default of 51 is the highest quantizer available for use in the h264 spec, and is extremely low quality. This default effectively disables qpmax. You may want to set this lower (values in the 30-40 range are generally as low as you'd go) if you want to cap the minimum quality x264 can output, but adjusting it is generally not recommended.

See also: qpmin, pbratio.

qpstep

Default: 4

Sets the maximum change in quantizer between two frames. If a frame is encoded at q20, the next frame's quantizer will be capped if it is lower than 16 or greater than 24.

The purpose behind this setting is to reduce the possibility of any large quality jumps in the output video. The reasoning is that it's better to slow this change over a few frames than do it in one. Remember that most videos at standard quality will range at most between quantizers 16 - 30, this setting can only distort the bitrate allocation for three frames max. The default value is a good one.

ratetol

Default: 1.0

Only applicable to 1pass bitrate encodes. Sets the percentage that x264 can miss the target average bitrate by. 1.0 = 1%. This means the final average bitrate (and corresponding filesize) will be within about ±1% of what you set.

You can set this to 'inf' to disable this overflow detection completely. You can set this to 0 to tell x264 it must exactly hit the target bitrate, but it might not always be possible and will often kill quality of the final few % of the video.

Many movies (any action movie for instance) are most complex at the climatic finale. As a 1pass encode doesn't know this, the number of bits required for the end is usually underestimated. A ratetol of inf can mitigate this by allowing the encode to function more like a crf encode, but the filesize will blow out.

ipratio

Default: 1.40

Sets the target average increase in bitrate for I-frames as compared to P-frames. Seen as 'keyframe boost' in xvid. Higher values increase the quality of I frames. This makes them better references, which can improve the overall image quality. The problem is that the extra bits taken by the I-frames are taken from the P and B-frames, which makes this variable a balancing act.

See also: pbratio

pbratio

Default: 1.30

Sets the target average reduction in bitrate for B-frames as compared to P-frames. This variable works more or less the same as ipratio above.

See also: ipratio

chroma-qp-offset

Default: 0

Normally, x264 encodes all three colour planes (luma, U (chroma), V (chroma)) at the same quantizer. This value will be added to the quantizers for the U and V planes. This allows you to bias x264 in favour of brightness (luma) by setting positive values (chroma fields will have higher quantizers), or in favour of colour (chroma). Remember that x264 encodes video as YV12, which means chroma takes up only half the space luma does anyway.

Note: x264 only encodes the luma and chroma planes at the same quantizer up to quantizer 29. After this, chroma is progressively quantized by a lower amount than luma until you end with luma at q51 and chroma at q39. This behavior is not adjustable, as it is required by the H.264 standard.

aq-mode

Adaptive Quantization Mode

Default: 1

Without AQ, x264 tends to underallocate bits to lower details sections. AQ is used to better distribute the available bits between all macroblocks in the video. This setting changes what scope AQ re-arranges bits in:

• 0: Do not use AQ at all.
• 1: Allow AQ to redistribute bits within each frame.
• 2: Allow AQ to redistribute bits across the whole video.
• 3: Auto-variance AQ with bias to dark scenes.

Recommendation: Default

See also: aq-strength

aq-strength

Adaptive Quantization Strength

Default: 1.0

Sets the strength of AQ bias towards low detail ('flat') macroblocks. Negative values are not allowed. Values more than a couple of hundred percent off from 1.0 are probably a bad idea.

Recommendation: Default

See also: aq-mode

pass

Default: Not Set

This is an important setting for 2pass encoding. It controls what x264 will do with the stats file. It has three settings:

• 1: Create a new statsfile. Use this on the first pass.
• 2: Read the statsfile. Use this on the final pass.
• 3: Read the statsfile, and update it as well.

The statsfile contains information about every input frame, which can be input to x264 in order to improve the output. The idea is you run a first pass to generate the statsfile, and the second pass will create an optimised encode of the video. The improvement is mostly gained from better ratecontrol.

See also: stats, bitrate.

stats

Default: "x264_2pass.log"

Set the location that x264 will read/write the pass statsfile from.

See also: pass

rceq

Default: "blurCplx^(1-qComp)"

Set the ratecontrol equation that x264 will use. Don't change this.

See also: qcomp, cplxblur, qblur

qcomp

Default: 0.60

Quantizer curve compression factor. 0.0 => Constant Bitrate, 1.0 => Constant Quantizer. Note that adaptive quantization partially replaces the effect of qcomp and x264 will internally raise qcomp to compensate based on the adaptive quantization strength.

rceq, cplxblur, qblur

cplxblur

Default: 20

Apply a gaussian blur with the given radius to the quantizer curve. This means that the quantizer assigned to each frame is blurred temporally with its neighbours to limit quantizer fluctuations.

See also: rceq, qcomp, qblur

qblur

Default: 0.5

Apply a gaussian blur with the given radius to the quantizer curve, after curve compression. Not a very important setting.

See also: rceq, qcomp, cplxblur

zones

With this option you can specify different CRF rates for different parts of the video. For example you specify CRF=20 for the full length of the video but you want to use CRF=18.5 from FRAME 27000 to 35000 and CRF=16.5 from 44000 to 49000 and CRF=17.5 from 75000 to 77500 and so on. This option is based on frame numbers.

This is the form:

zones=FromFrameA,ToFrameB,crf=18.5/FromFrameC,ToFrameD,crf=16.5/FromFrameE,ToFrameF,crf=17.5/...

zones=27000,35000,crf=18.5/44000,49000,crf=16.5/75000,77500,crf=17.5/...

qpfile

Manual override to standard ratecontrol. Specify a file that gives the quantizer and frametype for every frame. The format is "framenum frametype quantizer". For example:

0 I 18 < IDR (key) I-frame
1 P 20 < P-frame
2 B 22 < Referenced B-frame
3 i 21 < Non-IDR (non-key) I-frame
4 b 18 < Non-referenced B-frame

Analysis

partitions

Default: "p8x8,b8x8,i8x8,i4x4"

h264 video is split up into 16x16 macroblocks during compression. These blocks can be further split up into smaller partitions, which is what this options controls.

With this option, you enable individual partitions. Partitions are enabled per-frametype (ie I, P, B). The available partitions are: p8x8, p4x4, b8x8, i8x8, i4x4

• I: i8x8, i4x4
• P: p8x8 (also enables p16x8/p8x16), p4x4 (also enables p8x4/p4x8)
• B: b8x8 (also enables b16x8/b8x16)

You can also set "none" or "all".

p4x4 is generally not very useful and has an extremely high ratio of speed cost to resulting quality gain.

See also: 8x8dct

direct

Default: "spatial"

Set prediction mode for 'direct' motion vectors. There are two modes available: "spatial" and "temporal". You can also select "none" to disable direct MVs, and "auto" to allow x264 to swap between as it sees fit. If you set auto, x264 outputs information on the usage at the end of the encode. "auto" works best in a 2pass encode, but will work in single pass encodes too. In first-pass auto mode, x264 keeps a running average of how well each method has so far performed, and picks the next prediction mode from that. Note that you should only enable auto on the second pass if it was enabled on the first pass; if it wasn't, the second pass will default to temporal. Direct none wastes bits and is strongly discouraged.

Recommendation: "auto"

direct-8x8

Default: -1

Set the size of the direct prediction mode. Enabling direct-8x8 inference (on by default at most levels) may slightly improve quality when used with 8x8dct.

weightb

Default: Not Set

Allows non-symmetric weighting between references in B-frames. h264 allows you to 'weight' references in B-frames, which allows you to change how much each reference affects the predicted picture. Generally recommended for film footage and probably not useful for animated footage.

me

Default: "hex"

Set the full-pixel motion estimation method. There are four choices:

• dia (diamond) is the simplest search, consisting of starting at the best predictor, checking the motion vectors at one pixel upwards, left, down, and to the right, picking the best, and repeating the process until it no longer finds any better motion vector.
• hex (hexagon) consists of a similar strategy, except it uses a range-2 search of 6 surrounding points, thus the name. It is considerably more efficient than dia and hardly any slower, and therefore makes a good choice for general-use encoding.
• umh (uneven multi-hex) is considerably slower than hex, but searches a complex multi-hexagon pattern in order to avoid missing harder-to-find motion vectors. Unlike hex and dia, the merange parameter directly controls umh's search radius, allowing one to increase or decrease the size of the wide search.
• esa (exhaustive) is a highly optimized intelligent search of the entire motion search space within merange of the best predictor. It is mathematically equivalent to the bruteforce method of searching every single motion vector in that area, though faster. However, it is still considerably slower than UMH, with not too much benefit, so is not particularly useful for everyday encoding.
• tesa (transformed exhaustive) is an algorithm which attempts to approximate the effect of running a Hadamard transform comparison at each motion vector; like exhaustive, but a little bit better and a little bit slower.

See also: merange

merange

Default: 16

merange controls the max range of the motion search. For hex and dia, this is clamped to between 4 and 16, with a default of 16. For umh and esa, it can be increased beyond the default 16 to allow for a wider-range motion search, which is useful on HD footage and for high-motion footage. Note that for umh, esa, and tesa, increasing merange will significantly slow down encoding.

See also: me

mvrange

Default: 511.75

Set the maximum range of any one motion vector. The default value is the maximum specified by the h264 standard. It is not level or profile dependent, so don't touch it.

subme

Default: 6

Set the subpixel estimation complexity. Higher numbers are better. Levels 1-5 simply control the subpixel refinement strength. Level 6 enables RDO for mode decision, and level 8 enables RDO for motion vectors and intra prediction modes. RDO levels are significantly slower than the previous levels.

1. QPel SAD 1 iteration
2. QPel SATD 2 iterations
3. HPel on MB then QPel
4. Always QPel
5. Multi QPel + bime
6. RD on I/P frames
7. RD on all frames
8. RD refinement on I/P frames
9. RD refinement on all frames
10. QP-RD (requires --trellis=2, --aq-mode > 0)

psy-rd

Default: 1.0:0.0

First number is the strength of Psy-RDO to use (requires subme>=6 to activate). The second number is the strength of Psy-Trellis (requires trellis>=1 to activate). Note that Trellis is still considered 'experimental', and almost certainly is a Bad Thing for at least cartoons.

mixed-refs

Default: Not Set

Allow references to be selected on a per-8x8 partition, rather than per-macroblock basis. This improves quality when using multiple reference frames albeit at some speed cost.

See also: ref

no-chroma-me

Default: Not Set

Normally, motion estimation works off both the luma and chroma planes. This disables chroma motion estimation for a small speed boost.

Recommendation: Default

8x8dct

Default: Not Set

Adaptive 8x8 DCT enables the intelligent adaptive use of 8x8 transforms in I-frames.

Recommendation: Enabled

trellis

Default: Not Set

Performs Trellis quantisation to increase efficiency. On Macroblock provides a good compromise between speed and efficiency. On all decisions reduces speed further.

Recommendation: 1 (On Macro Block)

Note: Requires CABAC

no-fast-pskip

Default: Not Set

Disables early skip detection on P-frames. Fast skip detection increases speed but may cause slight blockiness in areas of solid colour or slight gradients such as dark scenes or sky.

Recommendation: Enabled

no-dct-decimate

Default: Not Set

Disables coefficient thresholding on P frames.

Recommendation: Default

nr

Default: Not Set

Performs fast noise reduction. Estimates film noise based on this value and attempts to remove it by dropping small details before quantization. This may not match the quality of a good external noise reduction filter, but it performs very fast.

Recommendation: Default or (100 to 1000 for denoising)

deadzone-inter/intra

Default: Not Set

Set the size of the inter / intra luma quantization deadzone. Deadzones should be in the range of 0 to 32. The deadzone value sets the level of fine detail that x264 will arbitrarily drop without attempting to preserve. Very fine detail is both hard to see and expensive to encode, dropping this detail without attempting to preserve it stops wasting bits on such a low-return section of the video.

Recommendation: Default

cqm

Default: Flat (Not Set)

Sets custom quantization matricies from the built in presets of flat or jvt.

Recommendation: Default

See also: cqmfile

cqmfile

Default: Not Set

Sets custom quantization matricies from a specified JM compatible file. Overrides any other --cqm* options.

Recommendation: Default

See also: cqm

cqm4* / cqm8*

Default: Not Set

• --cqm4: Set all 4x4 quant matrices. Takes a comma-separated list of 16 integers.
• --cqm8: Set all 8x8 quant matrices. Takes a comma-separated list of 64 integers.
• --cqm4i, --cqm4p, --cqm8i, --cqm8p: Set both luma and chroma quant matrices
• --cqm4iy, --cqm4ic, --cqm4py, --cqm4pc: Set individual quant matrices. Same switches exist for cqm8.

Recommendation: Default

Input/Output

output

Default: Not Set

Specifies output file name.

Recommendation: Use a custom output file name such as "Compressed Video.mp4"

sar

Default: Not Set

Specifies the Sample Aspect Ratio in for form of width:height. This is useful for encoding anamorphic video.

Recommendation: Default

fps

Default: Not Set

Specifies video framerate. In most instances the frame rate will be detected from the input video stream.

Recommendation: Default

seek

Default: Not Set

Specified the first frame to encode, allowing the encode to begin at any point in the source.

Recommendation: Default

frames

Default: Not Set

Specifies the maximum number of frames to encode, allowing the encode to finish at any point before the end of the source.

Recommendation: Default

level

Default: autodetect

Sets the level flag in the output bitstream (as defined by Annex A of the H.264 standard). Permissible levels include 1, 1b, 1.1, 1.2, 1.3, 2, 2.1, 2.2, 3, 3.1, 3.2, 4, 4.1, 4.2, 5, 5.1. If you do not put --level on the commandline, x264 will attempt to autodetect the level. This detection is not perfect, and may underestimate the level if you are not using VBV controls to limit the max bitrate.

If playback is intended on any consumer level product besides a HTPC, Level 4.1 is the maximum usually supported (Xbox 360, Playstation 3, Popcorn Hour A-100 Media Extender to name a few). The GPU-based DXVA decoders on PCs have a maximum level of 4.1 too. Blu-ray and HD DVD are Level 4.1.

Note that x264 treats this setting as an output flag only. It does not take any measures to ensure compliance with the level you specify.

Recommendation: 4.1

See also: ref

verbose

Default: Not Set

Displays statistics for each encoded frame.

Recommendation: Default

progress

Default: Not Set

Displays a progress indicator while encoding.

Recommendation: Default

quiet

Default: Not Set

Enables Quiet Mode, silencing status messages from x264.

Recommendation: Default

no-psnr

Default: Not Set

Disable the PSNR computation. Prevents PSNR calculations that are reported on completion. Provides a small increase in speed.

Recommendation: Enabled

no-ssim

Default: Not Set

Disable the SSIM computation. Prevents SSIM calculations that are reported on completion. Provides a small increase in speed.

Recommendation: Enabled

threads

Default: 1.5 * logical CPUs detected

Enables parallel encoding by using more than 1 thread to increase speed on multi-core systems. Previously, this threading was based on a slice encoding model, where the video was encoded in n slices (where n == threads). Since r607 this model was changed to sliceless threading, where the 'atomic unit' is now macroblock rows. The rest of this section refers to the latter system only.

The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16).

The default setting provides more or less optimum speed. If you want to reduce the quality loss, use one thread (Not Recommended, unless all other settings are already maxed)

Recommendation: Auto

See also: thread input

thread-input

Default: Not Set

Decodes the input video in a separate thread to the encoding process. Enabled implicitly when threads > 1.

Recommendation: Enabled when there is more than one logical CPU available.

non-deterministic

Default: Not Set

Slightly improve quality of SMP, at the cost of repeatability. Not for general use.

Recommendation: Default

See also: threads

no-asm

Default: Not Set

Disables all CPU optimisations. Useful for debugging or troubleshooting.

Recommendation: Default

visualize

Default: Not Set

Enables Macroblock Type visualisations over the encoded video. Useful for frame by frame debugging or analysis.

Recommendation: Default

sps-id

Default: Not Set

Set SPS (sequence parameter set) and PPS (picture parameter set) id numbers. Not for general use.

Recommendation: Default

aud

Default: Not Set

Use access unit delimiters. Not for general use.

Recommendation: Default

Old Settings

Analysis

b-rdo

removed since r996, it is now enabled automatically at subme >= 7

Default: Not Set

subme levels above 5 only affects I and P-frames by default. Set this to enable RDO calculations on B-frames as well.

See also: subme

bime

removed since r996, it is now enabled automatically at subme >= 5

Default: Not Set

Enables joint optimization of both Motion Vectors in B-frames. Bi-Directional Motion Estimation performs an additional search for forwards and backwards vectors when encoding bi-directional B-frames, improving quality.

Note: Does not effect B-frames encoded as direct/skip (no motion vector), forward (1 MV pointing to a past reference), backwards (1 MV pointing to a future reference).

Recommendation: Enabled

subme (old)

changed since r996:

subme 1~6 remain unchanged

new subme 7 == old subme 6 + b-rdo

new subme 8 == old subme 7 + b-rdo

new subme 9 == didn't exist, RD refinement in B-frames is completely new.

Default: 5 (pre r970), 6 (since r970)

Set the subpixel estimation complexity. Higher numbers are better. Levels 1-5 simply control the subpixel refinement strength. Level 6 enables RDO for mode decision, and level 7 enables RDO for motion vectors and intra prediction modes. Both the RDO levels are significantly slower than the previous levels.

See Also

• FFMPEG x264 encoding options guide. Very applicable to x264 options. Mostly written by x264 dev Dark Shikari.
• x264 in Avidemux guide. Written (partly) by this guy.