MeGUI/x264 Settings
x264 Settings
editFrame-type options
editkeyint
editInteger: 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
editInteger: 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.
scenecut
editInteger: 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
editDefault: 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
editInteger: 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
editNote: 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
editNote: 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
editInteger: 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
editDefault: 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
editDefault: 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: Default, always, unless your player just doesn't support it.
ref
editDefault: 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
editCompletely disables in-loop deblocking.
See Also: deblock
deblock
editDefault: 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
editDefault: 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
editqp
editDefault: 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
editDefault: 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
editDefault: 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.
vbv-maxrate
editDefault: 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
editDefault: 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
editDefault: 0
Sets the initial size of the VBV filled buffer size. Shouldn't be adjusted.
See also: vbv-maxsize, vbv-bufsize
qpmin
editDefault: 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.
qpmax
editDefault: 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.
qpstep
editDefault: 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
editDefault: 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
editDefault: 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
editDefault: 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
editDefault: 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
editAdaptive 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
editAdaptive 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
editDefault: 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.
stats
editDefault: "x264_2pass.log"
Set the location that x264 will read/write the pass statsfile from.
See also: pass
rceq
editDefault: "blurCplx^(1-qComp)"
Set the ratecontrol equation that x264 will use. Don't change this.
See also: qcomp, cplxblur, qblur
qcomp
editDefault: 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.
cplxblur
editDefault: 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.
qblur
editDefault: 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
editWith 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
editManual 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
editpartitions
editDefault: "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
editDefault: "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
editDefault: -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
editDefault: 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
editDefault: "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
fpel-cmp
editmerange
editDefault: 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
editDefault: 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.
mvrange-thread
editsubme
editDefault: 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.
- QPel SAD 1 iteration
- QPel SATD 2 iterations
- HPel on MB then QPel
- Always QPel
- Multi QPel + bime
- RD on I/P frames
- RD on all frames
- RD refinement on I/P frames
- RD refinement on all frames
- QP-RD (requires --trellis=2, --aq-mode > 0)
psy-rd
editDefault: 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
editDefault: 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
editDefault: 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
editDefault: Not Set
Adaptive 8x8 DCT enables the intelligent adaptive use of 8x8 transforms in I-frames.
Recommendation: Enabled
trellis
editDefault: 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
editDefault: 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
editDefault: Not Set
Disables coefficient thresholding on P frames.
Recommendation: Default
nr
editDefault: 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
editDefault: 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
editDefault: Flat (Not Set)
Sets custom quantization matricies from the built in presets of flat or jvt.
Recommendation: Default
See also: cqmfile
cqmfile
editDefault: Not Set
Sets custom quantization matricies from a specified JM compatible file. Overrides any other --cqm* options.
Recommendation: Default
See also: cqm
cqm4* / cqm8*
editDefault: 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
editoutput
editDefault: Not Set
Specifies output file name.
Recommendation: Use a custom output file name such as "Compressed Video.mp4"
sar
editDefault: Not Set
Specifies the Sample Aspect Ratio in for form of width:height. This is useful for encoding anamorphic video.
Recommendation: Default
fps
editDefault: Not Set
Specifies video framerate. In most instances the frame rate will be detected from the input video stream.
Recommendation: Default
seek
editDefault: Not Set
Specified the first frame to encode, allowing the encode to begin at any point in the source.
Recommendation: Default
frames
editDefault: 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
editDefault: 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
editDefault: Not Set
Displays statistics for each encoded frame.
Recommendation: Default
progress
editDefault: Not Set
Displays a progress indicator while encoding.
Recommendation: Default
quiet
editDefault: Not Set
Enables Quiet Mode, silencing status messages from x264.
Recommendation: Default
no-psnr
editDefault: Not Set
Disable the PSNR computation. Prevents PSNR calculations that are reported on completion. Provides a small increase in speed.
Recommendation: Enabled
no-ssim
editDefault: Not Set
Disable the SSIM computation. Prevents SSIM calculations that are reported on completion. Provides a small increase in speed.
Recommendation: Enabled
threads
editDefault: 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
editDefault: 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
editDefault: Not Set
Slightly improve quality of SMP, at the cost of repeatability. Not for general use.
Recommendation: Default
See also: threads
no-asm
editDefault: Not Set
Disables all CPU optimisations. Useful for debugging or troubleshooting.
Recommendation: Default
visualize
editDefault: Not Set
Enables Macroblock Type visualisations over the encoded video. Useful for frame by frame debugging or analysis.
Recommendation: Default
sps-id
editDefault: Not Set
Set SPS (sequence parameter set) and PPS (picture parameter set) id numbers. Not for general use.
Recommendation: Default
aud
editDefault: Not Set
Use access unit delimiters. Not for general use.
Recommendation: Default
Settings in Patches
editOld Settings
editFrame-type options
editRatecontrol
editAnalysis
editb-rdo
editremoved 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
editremoved 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)
editchanged 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
edit- 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.