x264 coding----Code Rate control

x264 is a H.264/MPEG4 AVC encoder, this guide will guide beginners on how to create high-quality H. S videos.

For ordinary users there are usually two code-rate control modes: CRF (Constant rates Factor) and dual pass ABR. Bitrate control is a method that determines how many bits are allocated for each video frame, and it determines the size and quality of the file.

If you need help compiling and installing libx264, check out the FFmpeg and x264 compilation Guide:

Http://ffmpeg.org/trac/ffmpeg/wiki/CompilationGuide

CRF (Constant rate Factor):

This method allows the entire file to achieve a specific video quality when the output file size is less important. The encoding mode provides maximum compression efficiency in a single pass encoding mode, and each frame can obtain the desired number of bits according to the required video quality. The downside is that you can't get a video file of a specific size, or control the output bit rate to a specific size.

1 Select a CRF value

The quantization scale range is 0~51, where 0 is lossless, 23 is the default, and 51 is probably the worst. The smaller the number, the better the image quality. Subjectively speaking, 18~28 is a reasonable range. 18 is often considered visually lossless, and its output video quality is identical or similar to the input video. But technically, it's still lossy compression.

If the CRF value increases by 6, the output code rate is approximately halved; if the CRF value is reduced by 6, the output code rate doubles. Usually choose a maximum CRF value on the premise of acceptable video quality, if the output video quality is good, then try a larger value, if it looks bad, then try a small value.

Note: The quantization scale mentioned in this article only applies to 8-bitx264 (10-bit x264 's quantization ratio is 0~63), and you can use the x264--help command to view the output bit depth in the outputs bit depth option, and 8bit is the most common in various versions.

2 Select a preset

A preset is a collection of parameters that can make a tradeoff between the encoding speed and the compression rate. A slightly slower-coded preset provides higher compression efficiency (the compression efficiency is measured in file size). This means that if you want a file of a specified size or a constant bitrate encoding mode, you can use a slower preset to get better quality. Similarly, for a constant-quality encoding mode, you can easily save bit rates by selecting a slower preset.

If you are patient, the usual advice is to use the slowest presets. All current presets are sorted in descending order of encoding speed: Ultrafast,superfast,veryfast,faster,fast,medium,slow,slower,veryslow,placebo

The default preset is medium, please ignore placebo because it is useless (see question and answer below). You can use--preset to view a list of presets, or you can view the configuration of the parameters used by the preset by x264--fullhelp.

You can change the parameter settings based on the uniqueness of the input content by using--tune. The current tune include: Film,animation,grain,stillimage,psnr,ssim,fastdecode,zerolantency. If your suppressed content is animated, you can use animation, or you want to retain the texture, that is, with grain. If you're not sure which option to use or if your input doesn't match any of the tune, you can ignore the--tune option. You can use--tune to view the tune list, or you can view the configuration of the parameters used by tune by x264--fullhelp.

Another optional parameter is--profile, which can limit your output to a specific H. s profile, which can be ignored unless your playback device supports only a certain profile. All profiles include: baseline,main.high,high10,high422,high444. Note the use of the--profile option and lossless encoding are incompatible.

As shown below, as a shortcut, you can list all possible internal preset and tune for FFmpeg by not declaring the contents of preset and tune.

Ffmpeg-i input-c:v Libx264-preset-tune Dummy.mp4

3 Using your Presets

Once you have selected a preset, apply it to your remaining unused video, which will ensure that they have the same video quality.

CRF Examples:

Next, you'll encode a video using x264, using a slightly slower preset than the normal preset, which gives you a slightly better video quality than the default setting.

Ffmpeg-i input-c:v libx264-preset slow-crf 22-c:a copy output.mkv

Note In this example, the audio stream of the input file is simply copied to the output and is not re-encoded.

two times mode:

This method works well if your goal is to determine the size of a file and the video quality between frames and frames is not important. This can be explained in a very good way by an example. Your video has a duration of 10 minutes (600 seconds) and requires the output to be 50MB, because bit rate = File Size/duration,

50mb*8192 (MB to kilobits)/600 s =683 kbps (global bitrate)

, 683kbps-128kbps (audio bitrate) =555kbps (video bit rate),

Two-side coding examples:

Ffmpeg-y-I input-c:v libx264-preset medium-b:v 555k-pass 1-an-f mp4/dev/null &&

Ffmpeg-i input-c:v libx264-preset medium-b:v 555k-pass 2-c:a libfdkaac-b:a 128k mp4 output.mp4

Note Windows users should use NUL to replace/dev/null

When using CRF, choose to use the slowest preset you can tolerate.

It is also recommended that you take a look at "making high-quality MPEG4 DVD movie video clips," A MPEG4 Encoder coding guide that will give you a deep understanding of how important it is for both sides to use each bit in an efficient way when you are facing limited storage space.

Lossless H .

You can encode a lossless output using-QP 0 or-CRF, for lossless compression we advocate the use of-QP over-CRF. Because the CRF in 8 bitx264 and bitx264 uses different values for lossless mode. For this ultrafast and Veryslow are two very useful presets, because the fast encoding speed and excellent compression ratio are usually two very important factors. Most non-ffmpeg players cannot play lossless mode, so if you consider compatibility issues, you may not be able to use lossless mode.

Examples of lossless compression (fast coding)

Ffmpeg-i input-c:v libx264-preset ULTRAFAST-QP 0 output.mkv

Example of lossless compression (high compression ratio)

Ffmpeg-i input-c:v libx264-preset VERYSLOW-QP 0 output.mkv

overriding default Presets

You can use-x264opts to rewrite presets or use libx264 's private options (you can view libx264 options in full with ffmpeg-h). We don't advise you to do this unless you know what you're doing. All presets are created by x264 developers and it is often a waste of time to tweak parameters to improve output quality.

Example:

Ffmpeg-i input-c:v libx264-preset slow-crf 22-x264opts keyint=123:min-keyint=20-c:a copy output.mkv

Additional Information :

ABR (Average Bit rate)

Ffmpeg-i input-c:v libx264-b:v 1000k ....

It provides a "running mean" goal, the ultimate goal is to match the final file size to this "global average" number (so basically, if the encoder encounters a lot of very small bit-rate overhead, it will encode at a bit rate below the required bitrate, But in the next few seconds the non-black frame will be encoded in a high-quality way to make the bitrate regression mean) using both sides of the encoding mode is this method becomes more effective, you can use with "max bit rate" to prevent the fluctuation of the bitrate.

CBR (Constant Bit rate)

In fact there is no CBR model, but you can "simulate" a constant bit rate setting by supplementing the ABR parameters, such as:

Ffmpeg-i input-c:v libx264-b:v 4000k-minrate 4000k-maxrate 4000k-bufsize 1835k out.m2v

In this example,-bufsize is a "bitrate control buffer", so it enforces a mean value (4000k) within each of the useful 1835k video data, so basically we think the receiver/terminal player will buffer so much data, Therefore there is no problem in the internal fluctuation of this data.

Of course, if there is only a black frame or a blank frame, it will take less bit rate than the demand bit rate (but it will improve the quality level as much as possible until the CRF).

CRF mode with maximum bit rate

You can use the CRF mode with the maximum bit rate by declaring the-CRF and-maxrate settings, such as:

Ffmpeg-i input-c:v LIBX264-CRF 20-maxrate 400k-bufsize 1835k

This will effectively lock the CRF value at 20, but if the output code rate exceeds 400kbps, in this case the encoder will reduce the quality to less than CRF 20.

Low Latency

x264 improves a-tune zerolatency option.

Compatibility:

If you want your video to be maximized and compatible with the target playback device (such as an older version of iOS or all Android devices), then you can do this:

-profile:v Baseline

This will turn off many advanced features, but it will provide good compatibility. Maybe you don't need these settings, because once you've used these settings, the bit rate will increase slightly over the same video quality compared to the higher coding grade.

For a list of profiles and descriptions of them, you can run x264--fullhelp

Keep in mind that Apple quick time only supports YUV 420 color space for x264 encoded video, and does not support any higher than Mian profile coding grade. This leaves only two compatible options baseline and main for quick time. Other coding grades Qucik time are not supported, although they can be played back on other playback devices.

Using the-SS and-t options, you can encode a paragraph instead of the entire video, so you can quickly understand the video encoding output.

-ss the offset time from the starting value, which can be in seconds or HH:MM:SS format

-T output delay, this value can be in seconds or HH:MM:SS format

Questions and Answers:

12 times encoding mode can provide better quality than CRF mode.

No, but it can control the target file size more precisely.

2 Why placebo is a waste of time.

Compared to Veryslow, it traded at a very high encoding time for about 1% of the video quality, a diminishing return, and veryslow compared to slower slow 5%;slow compared to 3%;slower and medium by a 5% increase ~10%.

3 Why my lossless output seems to be lossless.

This is due to the conversion of RGB->YUV, if you convert to yuv444, it is still lossless.

4 graphics card can speed up the x264 encoding.

No, x264 is not used (at least for now), and some private encoders use the GPU to speed up encoding, but that doesn't mean they are well optimized. It may be worse than x264, perhaps slower. Overall, FFmpeg has not supported GPUs so far.

Translation Note: x264 has started to support OpenCL-based graphics acceleration for frame type determination in version 2013.

5 suppressing video for quick time player

You need to use-PIX_FMT yuv420p to be your output to support QT player. This is because the quick time of Apple for the H. S video clip only supports YUV420 color space. Otherwise, the ffmpeg will output video formats that are incompatible with the quick time based on your video source or not ffmpeg based video.

Original address: http://blog.csdn.net/vblittleboy/article/details/8982857