• X264 Encoder Download
• X264 Encoder For Mac
• Best X264 Encoder Free
• Best X264 Encoder Software
• Best X264 Encoder Free
• How To Use X264 Encoder
• Best X264 Encoder Settings

x264 ffmpeg mapping and options guide

This guide maps most of libx264's options to FFmpeg's options along with detailed descriptions by x264 developer Dark_Shikari.

HandBrake’s H.264 encoder, x264, sets the appropriate level automatically based on all the other settings. To make sure your video doesn’t exceed a specific level, you simply have to make sure the other parameters fit within the constraints imposed by the level. The Constant Rate Factor (CRF) is the default quality (and rate control) setting for the x264 and x265 encoders, and it’s also available for libvpx. With x264 and x265, you can set the values between 0 and 51, where lower values would result in better quality, at the expense of higher file sizes. Higher values mean more compression, but at.

1. And constant quality (CRF, i.e. Quality-based encoding) is a very good method that would suit many users better than 2-pass, so you might want to consider it for future encodes. With 2-pass you have to estimate and try bitrates, but under CRF x264 determines the bitrate for you based on a quality level you specify.
2. We use and recommend the excellent, open-source x264 encoder, which is essentially the gold standard of H.264 video encoding today, and has been for several years. Since 2006, x264 has consistently won the annual MSU MPEG-4 AVC/H.264 Video Codecs Comparison competition every year, along with numerous other codec comparisons and reviews.

FFmpeg developer superdump has implemented x264 presets to FFmpeg. You can find his guide here.

Default psycho-acoustics tunings on x264 are much more mature and balanced for perceived quality than x265. (if you go higher than 4.1 preset). By using CRF 1518 vslow, Film TUNE, and 5.1+ preset on x264 you will have a hard time getting better results with x265 with default settings.

Frame-type options:

g <integer>
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

keyint_min <integer>
Minimum GOP length, the minimum distance between I-frames. Recommended default: 25

sc_threshold <integer>
Adjusts the sensitivity of x264's scenecut detection. Rarely needs to be adjusted. Recommended default: 40

bf <integer>
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.

Notes:

– Baseline Profile, such as that used by iPods, does not support B-frames. Recommended default: 16.

– If you want to generate H.264 baseline for older iPhone 3 phones, then do not use Advanced Parameters like B-frames or else the output will be generated as Main profile.

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.

b_strategy <integer>
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

bframebias
Make x264 more likely to choose higher numbers of B-frames during the adaptive lookahead. Not generally recommended. Recommended default: 0

flags2 +bpyramid
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.

X264 Encoder Download

coder
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)

refs <integer>
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

flags
Disable loop filter. Recommended default: -flags +loop (Enabled)

deblockalpha <integer>
deblockbeta <integer>
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:

cqp <integer>
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.

b <integer>
Enables target bitrate mode. Attempts to reach a specific bitrate. Should be used in 2-pass mode whenever possible; 1-pass bitrate mode is generally the worst ratecontrol mode x264 has.

crf <float>
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.

maxrate <integer>
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.

bufsize <integer>
Depends on the profile level of the video being encoded. Set only if you're encoding for a hardware device.

rc_init_occupancy <float>
Initial VBV buffer occupancy. Note: Don't mess with this.

qmin <integer>
Minimum quantizer. Doesn't need to be changed. Recommended default: -qmin 10

qmax <integer>
Maximum quantizer. Doesn't need to be changed. Recommended default: -qmax 51

qdiff <integer>
Set max QP step. Recommended default: -qdiff 4

bt <float>
Allowed variance of average bitrate

X264 Encoder For Mac

i_qfactor <float>
Qscale difference between I-frames and P-frames. Note: -i_qfactor is handled a little differently than –ipratio. Recommended: -i_qfactor 0.71

b_qfactor <float>
Qscale difference between P-frames and B-frames.

chromaoffset <integer>
QP difference between chroma and luma.

pass <1,2,3>
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.

rc_eq <string>
Ratecontrol equation. Recommended default: -rc_eq 'blurCplx^(1-qComp)'

qcomp <float>
QP curve compression: 0.0 => CBR, 1.0 => CQP. Recommended default: -qcomp 0.60

complexityblur <float>
Reduce fluctuations in QP (before curve compression) [20.0]

qblur <float>
Reduce fluctuations in QP (after curve compression) [0.5]

p8x8 (x264) /+partp8x8 (FFmpeg)

p4x4 (x264) /+partp4x4 (FFmpeg)

b8x8 (x264) /+partb8x8 (FFmpeg)

i8x8 (x264) /+parti8x8 (FFmpeg)

i4x4 (x264) /+parti4x4 (FFmpeg)

partitions <string> 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.

directpred <integer>
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.

flags2 +wpred
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.

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.

Best X264 Encoder Free

me_method <epzs,hex,umh,full> One of the most important settings for x264, both speed and quality-wise.

me_range <integer>
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.

1: Fastest, but extremely low quality. Should be avoided except on first pass 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.

8-9: Activates rate-distortion refinement, which uses RDO to refine both motion vectors and intra prediction modes. Slower than subme 6, but again, more efficient.

subq An extremely important encoding parameter which determines what algorithms are used for both subpixel motion searching and partition decision.

flags2 +mixed_refs
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.

flags2 +dct8x8
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.

0: disabled

1: enabled only on the final encode of a MB

2: enabled on all mode decisions

trellis <0,1,2>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.

flags2 -fastpskip
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.

Best X264 Encoder Software

Preamble

So, you want to learn more about video encoding? How to set up your stream for the best quality given your computer's hardware and connection limitations? Let's start with this video by Tom Scott.

He does a great job of giving a quick primer on how video encoding works, and you will hopefully have a better understanding of the topics and terminology that we'll be going over. All done? Great! Let's get started.

Before we get into the details, let me explain what this guide is not. This is not intended to be a fully detailed technical explanation of how x264 works; there are far better guides out there than what I can provide here. If you're interested in the nitty-gritty, head over to the doom9 forums, FFmpeg docs, or the x264 website and start digging. This is also not intended to be a 'best settings' guide, and I will not recommend any specific settings. This is intended to help you understand how video encoding in general works, and how to better identify potential issues with your settings and help you learn where to look to correct them.

Let me reiterate that there is no such thing as 'best settings'. Every single setup, for every single use case, will be different. As an example, I have 3 different sets of streaming encoding settings for the types of media I stream. One for fast motion games, one for desktop applications, and another for live video. If you are new to OBS or streaming in general, OBS Studio contains a feature known as the 'Auto-Configuration Wizard' which can be found in the Tools menu. This tool will test your system and your internet connection to determine what it can handle from both an encoding standpoint and a connection stability standpoint. However, the best way to find your best settings is to test, test, and test again.

This guide is focused entirely on streaming with the x264 encoder. This is what the vast majority of OBS users will be using when they stream. For local recordings, your choice of encoder is far less relevant than your actual settings and in many cases a hardware encoder will be better suited for you. You can learn more about local recording settings in this guide here: http://obsproject.com/forum/resources/obs-studio-high-quality-recording-and-multiple-audio-tracks.221/

It is important to understand that video encoding is a very resource intensive process, especially when attempting to do so in real-time. Hardware encoders - such as Nvidia NVENC, Intel QuickSync, or AMD VCE - can help with this as they use special hardware in your system dedicated to the task of video encoding. As a trade-off the overall quality per bitrate is lower than the CPU-based x264 in nearly all cases. For streaming where bitrate is usually a constraining factor, x264 is currently the best option for getting the most quality out of your stream.

Only been in recent years have standard consumer-grade computers reached the point where they can realistically provide the processing power to do live video encoding. Keep all this in mind when you wonder why your 8 year old dual core Pentium CPU cannot encode 1080p 60fps without failing miserably. Even the most powerful consumer CPUs can still struggle with the load of encoding a high-resolution, high-fps stream.

There are two primary components to the x264 encoder we'll be looking at: presets and bitrate.

Presets (anchor: presets)

x264 has several CPU presets, in increasing order from low CPU usage to high CPU usage: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo.

By 'preset', it means exactly what it sounds like: a set of pre-determined settings for x264 so that you don't have to set them all manually yourself to tweak things. These sets of settings have been tested by lots of people and are great for general use, depending on what you want to get out of your encoder. The actual details of what the settings are can be found here: http://dev.beandog.org/x264_preset_reference.html

The basic idea is that, all things being equal (same bitrate, etc), less CPU usage would result in worse quality, and more CPU usage would result in better quality, because the presets change how much time the encoder spends compressing each frame to look good within its setting constraints. Sometimes you need to reduce your CPU usage in order to get good performance, and the higher CPU usage presets can be difficult to use effectively with average consumer CPUs.

The last thing to note is that any preset lower than medium will have significant diminishing returns, and is not really worth the extra CPU cycles for streaming scenarios. Unless you are squinting at two identical streams side by side, you will not notice a difference. That said, if your CPU can handle it, there's no reason (outside your power bills) not to use them.

Here we have put together some comparison examples for how this actually looks in practice.

• x264, 1920x1080, 60fps, 2500kbps bitrate, high-detail low-motion scene:
• x264, 1920x1080, 60fps, 2500kbps bitrate, high-motion scene:

All these test are performed with exactly the same source video and bitrate, only the preset has changed.

However, it's important to note that all of this assumes that your PC can handle the preset and resolution/fps that you are trying to encode. If it cannot, you might start to notice skipping or image distortion on your stream, accompanied by the message in OBS stating: Encoding overloaded! The simple way of fixing this issue is to turn down the resolution and FPS of your stream to reduce the load, and failing that, you may need to turn down the preset. You can check our detailed guide on how to troubleshoot encoding issues here: https://obsproject.com/wiki/General-Performance-and-Encoding-Issues

Bitrate (anchor: bitrate)

The amount of energy the CPU spends compressing each frame isn't the only factor in video quality. Bitrate is also important, as it determines how much information you can put into each frame of video. If you are allowed to cram more data into each frame, you don't need lots of CPU spent on compression, so you can make each frame look better just by cranking up the bitrate. Remember how the Tom Scott video looked when he simulated lowering bitrate, with all other settings left the same? The same is true the other way. If you increase bitrate, you can make the video look better quality.

Thus, you can get a good-looking video with relatively low CPU usage by using a low-CPU usage preset (like superfast) with a higher bitrate. Just note that the amount of bitrate you'll need for this can vary greatly depending on the resolution and FPS you are trying to stream at. A 1080p 60fps stream at only 4000kbps bitrate using the ultrafast preset is not going to look very good. For reference, the YouTube encoding settings list is a great place to start. The list below differs slightly, and would be my personal recommendation as a starting point.

Best X264 Encoder Free

They are assuming x264 encoder with the veryfast preset, and low to medium motion in your scene. For 1080p 60fps in a high-motion scenario (like an action or FPS game), you would likely need more than 8,000kbps of bitrate at veryfast for it to look smooth during playback. Conversely, low-motion video (such as an RTS game or streaming Photoshop art creation) can work with much lower bitrate. These charts are intended to give you an idea on where to start.

How To Use X264 Encoder

The end result of using a lower encoder preset and upping the bitrate will probably look a bit different then comparable bitrate at higher presets, but the goal is to get roughly the same quality by trading off CPU usage for bandwidth. I recommend trying both and see which one works for you in terms of quality, CPU usage, and what your connection and streaming service can handle.

Best X264 Encoder Settings

For comparison, here is the same scene encoded using x264 veryfast in both a low-motion high-detail scene, and a high-motion scene.

• x264, 1920x1080, 60fps, veryfast preset, high-detail low-motion scene:
• x264, 1920x1080, 60fps, veryfast preset, high-motion scene:

As before with the preset test, these tests were performed with the exact same source video and preset, only the bitrate has changed.

I hope that this has helped you gain a better understanding of the basics on how video encoding works, the importance of bitrate, and the overall impact of changing these settings in OBS will have on your stream and performance of your PC. I will say again, the road to finding the perfect settings for your stream is to test, test, and test again. If you have any further questions, our forums and support chat are always open.

Happy creating!

Resource Links:

• Tom Scott video: https://www.youtube.com/embed/r6Rp-uo6HmI
• Advanced recording guide: http://obsproject.com/forum/resources/obs-studio-high-quality-recording-and-multiple-audio-tracks.221/
• x264 preset reference: http://dev.beandog.org/x264_preset_reference.html
• Doom9 (x264) forums: https://forum.doom9.org/
• FFmpeg wiki: https://trac.ffmpeg.org/wiki/Encode/H.264
• Official x264 website: https://www.videolan.org/developers/x264.html
• Official OBS wiki: https://obsproject.com/wiki/