x264 is a H.264/MPEG-4 AVC encoder. The goal of this guide is to inform new users how to create a high-quality H.264 video.

There are two rate control modes that are usually suggested for general use: Constant Rate Factor (CRF) or Two-Pass ABR. The rate control is a method that will decide how many bits will be used for each frame. This will determine the file size and also how quality is distributed.

Constant Rate Factor (CRF)

This method allows the encoder to attempt to achieve a certain output quality for the whole file when output file size is of less importance. This provides maximum compression efficiency with a single pass. Each frame gets the bitrate it needs to keep the requested quality level. The downside is that you can’t tell it to get a specific filesize or not go over a specific size or bitrate.

1. Choose a CRF value

The range of the quantizer scale is 0-51: where 0 is lossless, 23 is default, and 51 is worst possible. A lower value is a higher quality and a subjectively sane range is 18-28. Consider 18 to be visually lossless or nearly so: it should look the same or nearly the same as the input but it isn’t technically lossless.

The range is exponential, so increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate. General usage is to choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value and if it looks bad then choose a lower value.

Note: The CRF quantizer scale mentioned on this page only applies to 8-bit x264 (10-bit x264 quantizer scale is 0-63). You can see what you are using by referring to theffmpeg console output during encoding (yuv420p or similar for 8-bit, and yuv420p10le or similar for 10-bit). 8-bit is more common among distributors.

2. Choose a preset

A preset is a collection of options that will provide a certain encoding speed to compression ratio. A slower preset will provide better compression (compression is quality per filesize). This means that, for example, if you target a certain file size or constant bit rate, you will achieve better quality with a slower preset. Similarly, for constant quality encoding, you will simply save bitrate by choosing a slower preset.

The general guideline is to use the slowest preset that you have patience for. Current presets in descending order of speed are: ultrafast,superfast, veryfast, faster, fast,medium, slow, slower, veryslow, placebo. The default preset is medium. Ignore placebo as it is not useful (see FAQ). You can see a list of current presets with -preset help, and what settings they apply with x264 –fullhelp.

You can optionally use -tune to change settings based upon the specifics of your input. Current tunings include: film, animation, grain, stillimage, psnr, ssim,fastdecode, zerolatency. For example, if your input is animation then use the animation tuning, or if you want to preserve grain then use the grain tuning. If you are unsure of what to use or your input does not match any of tunings then omit the -tune option. You can see a list of current tunings with -tune help, and what settings they apply withx264 –fullhelp.

Another optional setting is -profile:v which will limit the output to a specific H.264 profile. This can generally be omitted unless the target device only supports a certain profile (see Compatibility). Current profiles include: baseline, main, high, high10, high422, high444. Note that usage of -profile:v is incompatible with lossless encoding.

As a shortcut, you can also list all possible internal presets/tunes for FFmpeg by specifying no preset or tune option at all:

MS DOS

1

ffmpeg -y -iinput -c:vlibx264 -preset -tune -fmp4/dev/null

Note: Windows users should use NUL instead of /dev/null.

3. Use your settings

Once you’ve chosen your settings apply them for the rest of your videos if you are encoding more. This will ensure that they will all have similar quality.

CRF Example

MS DOS

1

ffmpeg -iinput -c:vlibx264 -presetslow -crf22 -c:acopyoutput.mkv

Note that in this example the audio stream of the input file is simply ​stream copied over to the output and not re-encoded.

Two-Pass

This method is generally used if you are targeting a specific output file size and output quality from frame to frame is of less importance. This is best explained with an example. Your video is 10 minutes (600 seconds) long and an output of 50 MB is desired. Since bitrate = file size / duration:

Lossless H.264

You can use -qp 0 or -crf 0 to encode a lossless output. Use of -qp is recommended over -crf for lossless because 8-bit and 10-bit x264 use different -crf values for lossless. Two useful presets for this are ultrafast or veryslow since either a fast encoding speed or best compression are usually the most important factors. Most non-FFmpeg based players will not be able to decode lossless (but YouTube can), so if compatibility is an issue you should not use lossless.

Lossless Example (fastest encoding)

MS DOS

1

ffmpeg -iinput -c:vlibx264 -presetultrafast -qp0output.mkv

Lossless Example (best compression)

MS DOS

1

ffmpeg -iinput -c:vlibx264 -presetveryslow -qp0output.mkv

Overwriting default preset settings

You can overwrite default preset settings with the x264opts option, the x264-params option, or by using the libx264 private options (see ffmpeg -h encoder=libx264). This is not recommended unless you know what you are doing. The presets were created by the x264 developers and tweaking values to get a better output is usually a waste of time.

Additional Information & Tips

ABR (Average Bit Rate)

MS DOS

1

ffmpeg -iinput -c:vlibx264 -b:v1000koutput.mp4

This provides something of a “running average” target, with the end goal that the final file match this number “overall on average” (so basically, if it gets a lot of black frames, which cost very little, it will encode them with less than the requested bitrate, but then the next few seconds of (non-black) frames it will encode at very high quality, to bring the average back in line). Using 2-pass can help this method to be more effective. You can also use this in combination with a “max bit rate” setting in order to prevent some of the swings.

CBR (Constant Bit Rate)

There is no native CBR mode, but you can “simulate” a constant bit rate setting by tuning the parameters of ABR:

In the above example, -bufsize is the “rate control buffer” so it will enforce your requested “average” (4000k in this case) across each 1835k worth of video. So basically it is assumed that the receiver/end player will buffer that much data so it’s ok to fluctuate within that much.

Of course, if it’s all just empty/black frames then it will still serve less than that many bits/s but it will raise the quality level as much as it can, up to the crf level.

CRF with maximum bit rate

You can also also use a crf with a maximum bit rate by specifying both crf *and* maxrate settings, like

Low Latency

Compatibility

All devices

If you want your videos to have highest compatibility with target devices (older iOS versions or all Android devices):

MS DOS

1

-profile:vbaseline -level3.0

This disables some advanced features but provides for better compatibility. Typically you may not need this setting (and therefore avoid using -profile:v and -level), but if you do use this setting it may increase the bit rate quite a bit compared to what is needed to achieve the same quality in higher profiles.

Blu-ray

Pre-testing your settings

Encode a random section instead of the whole video with the -ss and -t options to quickly get a general idea of what the output will look like.

-ss: Offset time from beginning. Value can be in seconds or HH:MM:SS format.

-t: Output duration. Value can be in seconds or HH:MM:SS format.

faststart for web video

You can add -movflags +faststart as an output option if your videos are going to be viewed in a browser. This will move some information to the beginning of your file and allow the video to begin playing before it is completely downloaded by the viewer. It is not required if you are going to use a video service such as YouTube.

FAQ

Will two-pass provide a better quality than CRF?

Why is placebo a waste of time?

It helps at most ~1% compared to the veryslow preset at the cost of a much higher encoding time. It’s diminishing returns: veryslow helps about 3% compared to the slowerpreset, slower helps about 5% compared to the slow preset, and slow helps about 5-10% compared to the medium preset.

Why doesn’t my lossless output look lossless?

Blame the RGB to YUV color space conversion. If you convert to yuv444 it should still be lossless (which is the default now).

Will a graphics card make x264 encode faster?

Not necessarily. ​x264 supports OpenCL for some lookahead operations. There are also some proprietary encoders that utilize the GPU, but that does not mean they are well optimized, though encoding time may be faster; and they might be ​worse than vanilla x264, and possibly slower. Regardless, FFmpeg today doesn’t support any means of GPU encoding, outside of libx264.

Encoding for dumb players

You may need to use -pix_fmt yuv420p for your output to work in QuickTime and most other players. These players only supports the YUV planar color space with 4:2:0 chroma subsampling for H.264 video. Otherwise, depending on your source, ffmpeg may output to a pixel format that may be incompatible with these players.

Frame-type options:

–keyint <integer> (x264)
-g <integer> (FFmpeg)
Keyframe interval, also known as GOP length. This determines the maximum distance between I-frames. Very high GOP lengths will result in slightly more efficient compression, but will make seeking in the video somewhat more difficult. Recommended default: 250

–pre-scenecut (x264)UNKNOWN (FFmpeg)
Slightly faster (but less precise) scenecut detection. Normal scenecut detection decides whether a frame is a scenecut after the frame is encoded, and if so then re-encodes the frame as an I-frame. This is not compatible with threading, however, and so –pre-scenecut is automatically activated when multiple encoding threads are used.

–bframes <integer> (x264)-bf <integer> (FFmpeg)
B-frames are a core element of H.264 and are more efficient in H.264 than any previous standard. Some specific targets, such as HD-DVD and Blu-Ray, have limitations on the number of consecutive B-frames. Most, however, do not; as a result, there is rarely any negative effect to setting this to the maximum (16) since x264 will, if B-adapt is used, automatically choose the best number of B-frames anyways. This parameter simply serves to limit the max number of B-frames. Note that Baseline Profile, such as that used by iPods, does not support B-frames. Recommended default: 16

–b-adapt <integer> (x264)-b_strategy <integer> (FFmpeg)
x264, by default, adaptively decides through a low-resolution lookahead the best number of B-frames to use. It is possible to disable this adaptivity; this is not recommended. Recommended default: 1

0: Very fast, but not recommended. Does not work with pre-scenecut (scenecut must be off to force off b-adapt).

1: Fast, default mode in x264. A good balance between speed and quality.

2: A much slower but more accurate B-frame decision mode that correctly detects fades and generally gives considerably better quality. Its speed gets considerably slower at high bframes values, so its recommended to keep bframes relatively low (perhaps around 3) when using this option. It also may slow down the first pass of x264 when in threaded mode.

–b-pyramid (x264)-flags2 +bpyramid (FFmpeg)
Allows B-frames to be kept as references. The name is technically misleading, as x264 does not actually use pyramid coding; it simply adds B-references to the normal reference list. B-references get a quantizer halfway between that of a B-frame and P-frame. This setting is generally beneficial, but it increases the DPB (decoding picture buffer) size required for playback, so when encoding for hardware, disabling it may help compatibility.

–no-cabac (x264)-coder 0,1 (FFmpeg)
CABAC is the default entropy encoder used by x264. Though somewhat slower on both the decoding and encoding end, it offers 10-15% improved compression on live-action sources and considerably higher improvements on animated sources, especially at low bitrates. It is also required for the use of trellis quantization. Disabling CABAC may somewhat improve decoding performance, especially at high bitrates. CABAC is not allowed in Baseline Profile. Recommended default: -coder 1 (CABAC enabled)

–ref <integer> (x264)-refs <integer> (FFmpeg)
One of H.264’s most useful features is the abillity to reference frames other than the one immediately prior to the current frame. This parameter lets one specify how many references can be used, through a maximum of 16. Increasing the number of refs increases the DPB (Decoded Picture Buffer) requirement, which means hardware playback devices will often have strict limits to the number of refs they can handle. In live-action sources, more reference have limited use beyond 4-8, but in cartoon sources up to the maximum value of 16 is often useful. More reference frames require more processing power because every frame is searched by the motion search (except when an early skip decision is made). The slowdown is especially apparent with slower motion estimation methods. Recommended default: -refs 6

–deblock (x264)-deblockalpha <integer>(FFmpeg)-deblockbeta <integer>(FFmpeg)
One of H.264’s main features is the in-loop deblocker, which avoids the problem of blocking artifacts disrupting motion estimation. This requires a small amount of decoding CPU, but considerably increases quality in nearly all cases. Its strength may be raised or lowered in order to avoid more artifacts or keep more detail, respectively. Deblock has two parameters: alpha (strength) and beta (threshold). Recommended defaults:-deblockalpha 0 -deblockbeta 0 (Must have ‘-flags +loop’)

Ratecontrol:

–qp <integer>(x264)-cqp <integer>(FFmpeg)
Constant quantizer mode. Not exactly constant completely–B-frames and I-frames have different quantizers from P-frames. Generally should not be used, since CRF gives better quality at the same bitrate.

–crf <float>(x264)-crf <float>(FFmpeg)
Constant quality mode (also known as constant ratefactor). Bitrate corresponds approximately to that of constant quantizer, but gives better quality overall at little speed cost. The best one-pass option in x264.

–vbv-maxrate <integer>(x264)-maxrate <integer>(FFmpeg)
Specifies the maximum bitrate at any point in the video. Requires the VBV buffersize to be set. This option is generally used when encoding for a piece of hardware with bitrate limitations.

–vbv-bufsize <integer>(x264)-bufsize <integer> (FFmpeg)
Depends on the profile level of the video being encoded. Set only if you’re encoding for a hardware device.

–pass <1,2,3> (x264)-pass <1,2,3>(FFmpeg)
Used with –bitrate. Pass 1 writes the stats file, pass 2 reads it, and 3 both reads and writes it. If you want to use three pass, this means you will have to use –pass 1 for the first pass, –pass 3 for the second, and –pass 2 or 3 for the third.

One of H.264’s most useful features is the ability to choose among many combinations of inter and intra partitions. P-macroblocks can be subdivided into 16×8, 8×16, 8×8, 4×8, 8×4, and 4×4 partitions. B-macroblocks can be divided into 16×8, 8×16, and 8×8 partitions. I-macroblocks can be divided into 4×4 or 8×8 partitions. Analyzing more partition options improves quality at the cost of speed. The default is to analyze all partitions except p4x4 (p8x8, i8x8, i4x4, b8x8), since p4x4 is not particularly useful except at high bitrates and lower resolutions. Note that i8x8 requires 8x8dct, and is therefore a High Profile-only partition. p8x8 is the most costly, speed-wise, of the partitions, but also gives the most benefit. Generally, whenever possible, all partition types except p4x4 should be used.

–direct <integer>(x264)-directpred <integer>(FFmpeg)
B-frames in H.264 can choose between spatial and temporal prediction mode. Auto allows x264 to pick the best of these; the heuristic used is whichever mode allows more skip macroblocks. Auto should generally be used.

–direct-8×8 (x264)UNKONWN (FFmpeg)
This should be left at the default (-1).

–weightb (x264)-flags2 +wpred(FFmpeg)
This allows B-frames to use weighted prediction options other than the default. There is no real speed cost for this, so it should always be enabled.

–me (x264)-me_method (FFmpeg)
dia (x264) / epzs (FFmpeg) 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 (x264) / hex (FFmpeg) 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 (x264) / umh (FFmpeg) 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 (x264) / full (FFmpeg) 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.

One of the most important settings for x264, both speed and quality-wise.

–merange <integer>(x264)-me_range <integer>(FFmpeg)
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 and ESA, increasing MErange will significantly slow down encoding.

–mvrange(x264)UNKNOWN (FFmpeg)
Limits the maximum motion vector range. Since x264 by default limits this to 511.75 for standards compliance, this should not be changed.

2-5: Progressively better and slower, 5 serves as a good medium for higher speed encoding.

6-7: 6 is the default. Activates rate-distortion optimization for partition decision. This can considerably improve efficiency, though it has a notable speed cost. 6 activates it in I/P frames, and subme7 activates it in B frames.

–mixed-refs(x264)-flags2 +mixed_refs(FFmpeg)
H.264 allows p8x8 blocks to select different references for each p8x8 block. This option allows this analysis to be done, and boosts quality with little speed impact. It should generally be used, though it obviously has no effect with only one reference frame.

–no-chroma-me(x264)UNKNOWN (FFmpeg)
Chroma is used in the last steps of the subpixel refinement by default. For a slight speed increase, this can be disabled (at the cost of quality).

–8x8dct (x264)-flags2 +dct8x8(FFmpeg)
Gives a notable quality boost by allowing x264 to choose between 8×8 and 4×4 frequency transform size. Required for i8x8 partitions. Speed cost for this option is near-zero both for encoding and decoding; the only reason to disable it is when one needs support on a device not compatible with High Profile.

–trellis <0,1,2>(x264)-trellis <0,1,2>(FFmpeg)
0: disabled1: enabled only on the final encode of a MB2: enabled on all mode decisions

The main decision made in quantization is which coefficients to round up and which to round down. Trellis chooses the optimal rounding choices for the maximum rate-distortion score, to maximize PSNR relative to bitrate. This generally increases quality relative to bitrate by about 5% for a somewhat small speed cost. It should generally be enabled. Note that trellis requires CABAC.

–no-fast-pskip(x264)-flags2 -fastpskip(FFmpeg)
By default, x264 will skip macroblocks in P-frames that don’t appear to have changed enough between two frames to justify encoding the difference. This considerably speeds up encoding. However, for a slight quality boost, P-skip can be disabled. In this case, the full analysis will be done on all P-blocks, and the only skips in the output stream will be the blocks whose motion vectors happen to match that of the skip vector and motion vectors happen to match that of the skip vector and which have no residual. The speed cost of enabling no-fast-pskip is relatively high, especially with many reference frames. There is a similar B-skip internal to x264, which is why B-frames generally encode much faster than P-frames, but it cannot be disabled on the commandline.

–no-dct-decimate(x264)UNKNOWN (FFmpeg)
By default, x264 will decimate (remove all coefficients from) P-blocks that are extremely close to empty of coefficents. This can improve overall efficiency with little visual cost, but may work against an attempt to retain grain or similar. DCT decimation should be left on unless there’s a good reason to disable it.

–nr(x264)UNKNOWN (FFmpeg)
a fast, built-in noise reduction routine. Not as effective as external filters such as hqdn3d, but faster. Since x264 already naturally reduces noise through its quantization process, this parameter is not usually necessary.

–deadzone-inter(264)
–deadzone-intra (x264)UNKNOWN (FFmpeg)UNKNOWN (FFmpeg)
When trellis isn’t activated, deadzone parameters determine how many DCT coefficients are rounded up or down. Rounding up results in higher quality and more detail retention, but costs more bits–so rounding is a balance between quality and bit cost. Lowering these settings will result in more coefficients being rounded up, and raising the settings will result in more coefficients being rounded down. Recommended: keep them at the defaults.

–cqm (264)
–cqpfile(x264)UNKNOWN (FFmpeg)UNKNOWN (FFmpeg)
Allows the use of a custom quantization matrix to weight frequencies differently in the quantization process. The presets quant matrices are “jvt” and “flat”. –cqpfile reads a custom quant matrices from a JM-compatible file. Recommended only if you know what you’re doing.

Cutting small sections

To extract only a small segment in the middle of a movie, it can be used in combination with -t which specifies the duration, like -ss 60 -t 10 to capture from second 60 to 70. Or you can use the -to option to specify an out point, like -ss 60 -to 70 to capture from second 60 to 70. -t and -to are mutually exclusive. If you use both, -t will be used.

Note that if you specify -ss before -i only, the timestamps will be reset to zero, so -t and -to have the same effect:

MS DOS

1

2

ffmpeg -ss00:01:00 -ivideo.mp4 -to00:02:00 -ccopycut.mp4

ffmpeg -ivideo.mp4 -ss00:01:00 -to00:02:00 -ccopycut.mp4

Here, the first command will cut from 00:01:00 to 00:03:00 (in the original), whereas the second command would cut from 00:01:00 to 00:02:00, as intended.

Time unit syntax

Note that you can use two different time unit formats: sexagesimal (HOURS:MM:SS.MICROSECONDS, as in 01:23:45.678), or in seconds. If a fraction is used, such as 02:30.05, this is interpreted as “5 100ths of a second”, not as frame 5. For instance, 02:30.5 would be 2 minutes, 30 seconds, and a half a second, which would be the same as using 150.5 in seconds.

Doing a bitstream copy gives me a broken file?

If you use -ss with -c:v copy, the resulting bitstream might end up being choppy, not playable, or out of sync with the audio stream, since ffmpeg is forced to only use/split on i-frames.

Concat demuxer

The concat demuxer was added to FFmpeg 1.1. You can read about it in the documentation.

Instructions

Create a file mylist.txt with all the files you want to have concatenated in the following form (lines starting with a # are ignored):

MS DOS

1

2

3

4

#thisisacomment

file'/path/to/file1'

file'/path/to/file2'

file'/path/to/file3'

Note that these can be either relative or absolute paths. Then you can stream copy or re-encode your files:

MS DOS

1

ffmpeg -fconcat -imylist.txt -ccopyoutput

It is possible to generate this list file with a bash for loop, or using printf. Either of the following would generate a list file containing every *.wav in the working directory:

MS DOS

1

2

3

4

#withabashforloop

forfin./*.wav;doecho "file '$f'" >> mylist.txt; done

#orwithprintf

printf"file '%s'\n"./*.wav>mylist.txt

If your shell supports process substitution (like Bash and Zsh), you can avoid explicitly creating a list file and do the whole thing in a single line. This would be impossible with the concat protocol (see below):

Concat protocol

While the demuxer works at the stream level, the concat protocol works at the file level. Certain files (mpg and mpeg transport streams, possibly others) can be concatenated. This is analogous to using cat on UNIX-like systems or copy on Windows.

Instructions

MS DOS

1

ffmpeg -i"concat:input1.mpg|input2.mpg|input3.mpg" -ccopyoutput.mpg

If you have MP4 files, these could be losslessly concatenated by first transcoding them to mpeg transport streams. With h.264 video and AAC audio, the following can be used:

If you’re using a system that supports named pipes, you can use those to avoid creating intermediate files – this sends stderr (which ffmpeg sends all the written data to) to /dev/null, to avoid cluttering up the command-line:

All MPEG codecs (H.264, MPEG4/divx/xvid, MPEG2; MP2, MP3, AAC) are supported in the mpegts container format, though the commands above would require some alteration (the-bsf bitstream filters will have to be changed).