X264 Encoding Suggestions

转自：http://mewiki.project357.com/wiki/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.filex264 --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 = 0if b-adapt=2 and not (nopass or pass2):    delay = MAX(bframes,3)*4else:    delay = bframesif mb-tree or vbv:     delay = MAX(delay,rc_lookahead)if not sliced-threads:    delay = delay + threads - 1delay = delay + sync-lookaheadif 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