X264 Encoding Suggestions



General Tips

• Don't use x264 as a replacement for a denoising filter. Ensure that your input looks like what you want as output (ignoring the loss in quality from compression). Doing anything else causes x264 to run less efficiently.
• If you aren't seeing 100% CPU usage while encoding, the problem may lie with your input:
  • Raw YUV input can easily be constrained by your IO system's speed. The size of a raw frame can be calculated as: width * height * bitdepth (12 for YV12) / 8 (bits -> bytes) / 1024 (bytes -> kbytes) / 1024 (kbytes -> mbytes).
  • Avisynth scripts run in a single thread. Some filters can spawn extra threads for themselves but this doesn't give huge gains.
  • ffmpeg (and therefore ffms2) is only supported as a single-threaded decoder in x264.
• The Flash h.264 decoder (and others) didn't support weighted P-frame prediction (--weightp) until version 10.1, which still isn't widely deployed (>90%) at time of writing. Set --weightp 0 when encoding for Flash if this is still the case.
• Apple's QuickTime Player has various decoding issues, especially related to reference frame count. See the QuickTime encoding suggestions if you want to maintain QuickTime compatibility, and you should since they make up a large portion of computer users.

Commandline Suggestions

You can divide x264 settings into three groups:

1. Those you should touch directly

Things like --bitrate, --keyint, --slices and so forth. They depend on the requirements of your decoder and thus are ignored by x264's preset system.

2. Those you should touch via the preset system

Before the preset system existed people wrote giant commandlines specifying every option by hand. There were arguments over whether --subme 9 with --me hex was better or worse than --subme 7 with --me tesa. Crazy! Do your part to bury these memories by using --preset, --tune and --profile.

3. Those you should avoid remembering exist

--qcomp, --scenecut, and so on. Settings that probably should be built-in constants now. Their use in contemporary commandlines serve no purpose other than causing pain among readers when asking for help. Seriously, people-tweaking-obscure-parameters-because-of-a-hazy-belief-it-helps, knock it off.

VBV Encoding

The VBV (Video Buffer Verifier) system in x264 is used to constrain the output bitrate so it is suitable for streaming in a bandwidth constrained environment.

The h.264 VBV model is based around the idea of a "VBV buffer" on the decoder side. As the h.264 stream is downloaded by the client it's stored in the VBV buffer. A frame must be fully downloaded into the VBV buffer before it can be decoded.

x264 has three options that control the VBV buffer:

1. The buffer's size is specified in kbit with --vbv-bufsize,
2. The rate at which the buffer fills is specified in kbit/sec by --vbv-maxrate,
3. The proportion of the buffer that must be filled before playback can start is specified by --vbv-init.

When using VBV, you always need to set the first two options and should never need to set the last one.

Examples

Example 1

Scenario: Encoding a movie to a file on your hard drive to play at a later date.

Suggestion: Do not specify any VBV settings. Your hard drive has a fast enough transfer rate that there's no need to specify any VBV constraints.

Example 2

Scenario: Encoding a video that's suitable for muxing to a Blu-ray compatible file.

Suggestion: The Blu-ray specification specifies a 40 Mbit maximum data rate (for the video) and a 30 Mbit buffer. So, specify --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000.

Note: x264 needs more options to output a fully compliant Blu-ray file. But these options are all you need for VBV compliancy.

Example 3

Scenario: Streaming a video via Flash on a website, like Youtube.

Suggestion: You want the video to start very quickly, so there can't be more than (say) 0.5 seconds of buffering. You set a minimum connection speed requirement for viewers of 512kbit/sec. Assume that 90% of that bandwidth will be usable by your site, and that 96kbit/sec will be used by audio, which leaves 364kbit/sec for x264. So, specify --vbv-maxrate 364 --vbv-buffer 182.

Note: There are more factors than just the video VBV settings when looking at the start delay for online streaming. The above example is for a perfect world where these factors don't exist.

Blu-ray Encoding

Someone else (kierank) has done all the hard work, you can find full instructions on creating Blu-ray compliant files with x264 here. The short answer for 1080p encoding is as follows:

x264 --bluray-compat --bitrate X --preset veryslow --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 \
    --vbv-bufsize 30000 --level 4.1 --keyint X --b-pyramid strict --slices 4 --fake-interlaced \
    --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 \
    --pass 1 -o output.file input.file
x264 --bluray-compat  --bitrate X --preset veryslow --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 \
    --vbv-bufsize 30000 --level 4.1 --keyint X --b-pyramid strict --slices 4 --fake-interlaced \
    --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 \
    --pass 2 -o output.file input.file

Set keyint to your fps. Use a faster preset if desired. Add a --tune parameter if desired. --weightp is disabled because some hardware decoders have problems with it, not because it's mandated by the Blu-ray spec.

Encoder latency

Depending on the encoder settings you configure, x264 will keep an internal buffer of frames to improve quality. When you're just encoding a file offline this is irrelevant, but if you're working in a broadcast or streaming environment this delay can be unacceptable.

You can calculate the number of frames x264 buffer (the encoder latency) using the following pseudocode. If you use the libx264 API, see also x264_encoder_delayed_frames.

delay = 0

if b-adapt=2 and not (nopass or pass2):
    delay = MAX(bframes,3)*4
else:
    delay = bframes

if mb-tree or vbv:
     delay = MAX(delay,rc_lookahead)

if not sliced-threads:
    delay = delay + threads - 1

delay = delay + sync-lookahead

if vbv and (vfr-input or abr or pass1:
    delay = delay + 1

Reducing x264's latency is possible, but reduces quality. If you want no latency, set --tune zerolatency. If you can handle even a little latency (ie under 1 second), it is well worth tuning the options to allow this. Here is a series of steps you can follow to incrementally reduce latency. Stop when your latency is low enough:

1. Start with defaults
2. Kill sync-lookahead
3. Drop rc-lookahead to no less than ~10
4. Drop threads to a lower value (i.e. say 6 instead of 12)
5. Use sliced threads
6. Disable rc-lookahead
7. Disable b-frames
8. Now you're at --tune zerolatency

QuickTime-compatible Encoding

There is a lot of very outdated misinformation surrounding how to encode h.264 videos that play perfectly in QuickTime. For instance that "QT supports only 1 B-Frame" and "QT doesn't support pyramidal B-Frames" which are both false as of QuickTime Player 7.7. There also used to exist a qpmin/dct bug in early versions of QuickTime Player where the player couldn't deal with a low quantizer (below 4) combined 8x8 DCT Transforms; however, that has been fixed as of QuickTime Player X.

QuickTime Player X compatibility

The Apple h.264 decoder component released with the launch of QuickTime Player X is a pretty good decoder and has only one big remaining bug. However, before we go on, you might wonder about all those people that are stuck on older versions of QuickTime Player, refusing to upgrade to QTX. That is no problem at all, because the actual decoder that is used systemwide by OS X (including by QuickTime) is a separate component from the player, and will have been updated through Software Updates even though they may not have downloaded the actual player update. So, any time we refer to QuickTime Player X, assume that anyone with 10.6 Snow Leopard or higher has that bug-fixed Apple h.264 decoder component, even if they don't specifically have QTX.

There is now just a single remaining major Apple h.264 decoder flaw:

• A high number of reference frames (15 or more, to be precise) combined with a high number of B-Frames produces blocky, distorted video output. This is an issue you will encounter with the "veryslow" preset, since it uses up to 16 reference frames.

Solution:

• Limit the number of reference frames to any number between 1-14. Look up the acceptable number of reference frames for your desired h.264 level and video resolution and make sure never to exceed that value or 14, whichever comes first. However, there is rarely any point in exceeding 5 reference frames anyway, and 4 frames is the maximum allowed for 1080p content in the most common levels, so a good choice is to simply pick 4 reference frames for all your encodes regardless of video resolution: --ref 4 (For Level 5+ encodes, you may want to refer to the level specifications and pick a higher number as long as you don't exceed 14.)

QuickTime Player 7.7 compatibility

Any operating system that has the option of installing QuickTime Player X will have the updated QTX decoder. That sadly means only OS X 10.6 Snow Leopard users and higher. So, if you want 10.5 Leopard users to be able to play your videos, you'll have to read this section as well since they are stuck on QuickTime Player 7.7. Note that the number of active Leopard users is in the 10% range and falling, so you may decide not bother. Then again, it's easy enough to add compatibility with their outdated Apple h.264 decoder at a very tiny penalty to quality, so you will probably find it worth it.

The decoder flaw:

• A low quantizer (below 4) combined with 8x8 DCT Transforms produces garbled decode results in QuickTime Player 7.7 or earlier.

Solution:

• Prevent the encoder from using quantizers below 4 with --qpmin 4. You will take an extremely minor quality loss, but far less than you would have if you had disabled 8x8 DCT instead.

Conclusion

Forget everything you may have read elsewhere on the internet. It is extremely outdated and hasn't been true for many years.

The simplest advice for QuickTime compatibility: Combine both solutions to get the most compatible encodes, fully playable by anyone on 10.5 Leopard or above, giving you 99% of the Mac userbase.

Just encode all your videos with --ref 4 --qpmin 4 and be safe in the knowledge that it will work for all Mac users that matter!

原文地址：http://mewiki.project357.com/wiki/X264_Encoding_Suggestions