The goal of this document is to show typical codec�s analysis to support future tuning. x264 codec implementing H.264 standard was chosen as an example. Strong and weak spots of x264 in terms of encoding speed and video quality are found and recommendations on use of codec�s presets are given. This document may be of interest to companies analyzing usefulness of tuning/elaboration of their own codecs and also for users of x264 codec. More about YUVsoft�s services on developing, tuning and testing videocodecs and other R&D services and opportunities may be found at www.yuvsoft.com/technologies/codecs_testing/index.html.

Codec

We have chosen x264 as a demo codec because of few reasons. x264 has a lot of parameters for precise tuning, and many features of H.264 standard are implemented in it. Open sources of the codec allow a more detailed analysis of obtained testing results. Another reason is codec�s quality � according to H.264 comparisons[1], x264 is one of the best H.264 codecs for the present time.

We used a codec compiled from sources labeled as �x264-snapshot-20060406-2245�. The reference codec JM 9.8 was used for decoding.

Sequences

Sequence	Number of frames	Frames per second	Resolution and color space
1. foreman	300	30	352x288(YV12)
2. susi	374	25	704x576(YV12)
3. bbc	374	25	704x576(YV12)
4. battle	1599	24	704x288(YV12)
5. simpsons	365	24	720x480(YV12)
6. matrix	239	25	720x416(YV12)
7. mobile	372	25	704x576(YV12)

Our test set includes mainly movies and standard sequences from different sources with different types of motion. A more detailed description of all used sequences can be found in Appendix: Sequences Description.

Methodology

Averaging Methods and Explanation of Charts

One of the most important characteristics of a codec is quality of encoded video. Besides problems regarding how to measure �video quality�, there are difficulties in comparing different codecs or modes of functioning of a certain codec since it is non-trivial to represent quality by a single value. Some reasonable assumptions and well-grounded aggregation methods are necessary to perform such a comparison. The following approach was used.

First of all, we run all chosen presets of x264 for all test sequences at 10 different bitrates: 100, 225, 340, 460, 700, 938, 1140, 1340, 1840 and 2340 Kbps. Encoded sequences were compared with corresponding originals using objective metrics such as PSNR, SSIM, etc. It made us able to create and operate with Bitrate/Quality charts or Rate-Distortion curves of the codec. These data are necessary to correctly compare different modes (presets) of the codec, or, as it also might be the case, to correctly compare different codecs. We used the notion of �relative bitrate� meaning what bitrate in percents should be to achieve the same quality (by, for example, PSNR criterion) as for some reference preset whose bitrate is taken for 100%.

The first step to get relative bitrate of two presets (codecs) is �rotating� of Rate-Distortion (RD) charts, changing axis of the charts (Figure 1, Figure 2). It allows us to calculate ratio of bitrates for the same quality. The advantage of bitrates ratio for the same quality instead of, for example, PSNR difference for the same bitrate, is that bitrates ratio does not generally depend on an objective quality metric being used.

After that it is necessary to choose interval of averaging. We used an internal area of RD curves where missed bitrate values can be interpolates between the nearest values (see Figure 2). It means that we did not use extrapolation because of big possible mistakes of RD curves extrapolation. Linear interpolation was used to get values between the existing points. Previous experiments convinced us that more complex interpolation methods usually give very little for better accuracy.

To get average values we calculated sizes of areas under the curves and divided one by the other (see Figure 3).


Figure 1. Source RD data	Figure 2. Axis rotation and interval choosing

Figure 3. Ratio of areas

To get relative encoding time for two presets, we calculated relative time for each sequence and use arithmetic mean to average those values. For each sequences we divided total encoding time for each preset (time to encode sequence with 10 bitrates) by encoding time of a chosen reference preset.

This method allows us to take into account small sequences with the same weight as long sequences.

Average Relative Bitrate graphs, which are often used in this document, are a visualization of relative speed and relative bitrate (for the same quality) for all presets. A certain default preset was selected as a reference; it is always placed in point (1, 1) on these figures. For each preset relative time and relative bitrate were calculated against the reference and placed on the charts as shown on Figure 4.

Figure 4. Speed (Encoding Time)/Quality chart example

Metrics Used in Comparison

During testing the following metrics were calculated:

� PSNR (Y component)

� SSIM (Y component)

� Blocking (Y component)

Information of these metrics can be found here:

http://www.compression.ru/video/quality_measure/info_en.html

All types of analysis in this document were made using Y-PSNR metric. Relative bitrates were calculated using this classic metric, as described in section �Averaging Methods and Explanation of Charts�.

Presets

We have chosen many different presets (codec parameters combinations) in order to try to select optimal presets in terms of speed and objective video quality.

Since we can�t test presets on all sequences available all over the world, so we compared presets on test sequences that were enumerated above. This test set is deemed to be representative for common applications.

The chosen presets are described in the following table. It might be convenient to print this table for a more convenient study of subsequent charts.

	Preset	Comments
1.	default	All parameters are set to their default values and the command line looks like: x264 ‑‑no-psnr ‑‑bitrate=<target_bitrate> ‑‑fps=<fps> -o <output> <input> <width>x<height> Other presets add additional parameters to this command line.
2.	-t 1	We want to see how trellis works in terms of speed/quality tradeoff. Trellis is a deletion of nonzero coefficients after DCT and quantization if it is among a group of zero coefficients. For example, if we have sequence 00001000 of quantized DCT coefficients, after trellis RDO optimization the only �one� can be zeroed.
3.	-t 2
4.	‑‑nr 5	Switches noise reduction on.
5.	‑‑no-fast-pskip	Disable early skip detection on P-frames.
6.	‑‑subme 1	Different modes of block partitioning and sub-pixel motion estimation. �‑‑subme 7� turns on optimal sub-block partitioning by encoding all partitions and choosing between them, so it works very long, but it can give quality comparable with multi-pass algorithms.
7.	‑‑subme 3
8.	‑‑subme 6
9.	‑‑subme 7
10.	‑‑me dia	Different motion estimation modes.
11.	‑‑me umh
12.	‑‑me esa
13.	‑‑subme 6 ‑‑b-rdo ‑b 3	RD-based mode decision for B-frames. We need to turn on subme=6 in order to make it works.
14.	‑‑no-chroma-me	Use only luma in motion estimation. It can improve speed, but if an image contains regions that have the same luma component, but different colors (�Mobile� sequence has such regions), motion estimation will fail.
15.	‑‑weightb -b 3
16.	-b 3 ‑‑b-bias 5 ‑‑b-pyramid ‑‑weightb ‑‑b-rdo ‑‑subme 6 ‑‑bime
17.	‑‑direct none	Several motion vector prediction modes.
18.	‑‑direct spatial
19.	‑‑direct temporal
20.	‑‑direct auto
21.	‑‑analyse=none	Different modes of MB partitioning.
22.	‑‑analyse=all -8	Different modes of MB partitioning.
23.	‑‑pass 1 ‑‑pass 2	Multipass algorithms. They give better quality, but work two and three times slower, respectively.
24.	‑‑pass 1 ‑‑pass 3 ‑‑pass 2
25.	‑‑ratetol 0.1	Test how quality and speed would change, if the codec has to keep target bitrate more precisely.
26.	‑‑nf	Disable loop filter (turn off deblocking).
27.	‑‑no-cabac	Use CAVLC (variable length codes) instead of CABAC (arithmetic compression).
28.	‑‑ref 10	Use greater number of reference frames. Can significantly improve motion compensation accuracy.
29.	‑‑scenecut 10	Insert extra I-frames more aggressively.
30.	‑‑me=umh ‑‑merange=32 ‑‑subme=6 ‑‑ref=16 ‑‑analyse=all ‑‑direct=spatial ‑‑pbratio=1.5 ‑‑bframes=3 ‑‑weightb ‑‑pass=1 ‑‑me=umh ‑‑merange=32 ‑‑subme=6 ‑‑ref=16 ‑‑analyse=all< br> ‑‑direct=spatial ‑‑pbratio=1.5 ‑‑bframes=3 ‑‑weightb ‑‑pass=2	Encode with the best possible quality available.
31.	‑‑me=dia ‑‑merange=16 ‑‑subme=1 ‑‑analyse=none ‑‑direct=spatial ‑‑pbratio=1.5 ‑‑bframes=1	Here we take the previous preset () and decrease parameter values in order to reach good quality with better speed.
32.	‑‑no-b-adapt ‑‑no-cabac ‑‑analyse=p8x8 ‑‑me dia ‑‑subme=1 ‑‑no-chroma-me
33.	-b 4 ‑‑b-pyramid -r 16 ‑‑analyse=all ‑‑direct auto ‑‑weightb ‑‑me umh ‑‑subme=7 ‑‑b-rdo ‑‑bime -8 ‑‑pass=1 -b 4 ‑‑b-pyramid -r 16 ‑‑analyse=all ‑‑direct auto ‑‑weightb ‑‑me umh ‑‑subme=7 ‑‑b-rdo ‑‑bime -8 ‑‑pass=2
34.	‑‑me=umh ‑‑merange=32 ‑‑subme=6 ‑‑ref=16 ‑‑analyse=all ‑‑direct=spatial ‑‑pbratio=1.5 ‑‑bframes=3 ‑‑weightb
35.	‑‑me=umh ‑‑merange=16 ‑‑subme=6 ‑‑ref=8 ‑‑analyse=all ‑‑direct=spatial ‑‑pbratio=1.5 ‑‑bframes=3
36.	‑‑me=umh ‑‑merange=16 ‑‑ref=4 ‑‑analyse=all ‑‑direct=spatial ‑‑pbratio=1.5 ‑‑bframes=3 ‑‑weightb
37.	-b 3 ‑‑b-bias 5 ‑‑b-pyramid ‑‑weightb ‑‑b-rdo ‑‑bime ‑‑subme 7 -8 ‑‑ref 4
38.	‑‑subme 7 ‑‑ref 10	We want to evaluate relative influence of partitioning, motion compensation and trellis parameters.
39.	‑‑subme 7 -t 1
40.	‑‑ref 10 -t 1
41.	-b 3 ‑‑b-bias 5 ‑‑b-pyramid ‑‑weightb ‑‑b-rdo ‑‑bime -8 -t 1	Some other variants of good quality presets.
42.	‑‑subme 6 -b 5 ‑‑b-bias 5 ‑‑b-pyramid
43.	-b 4 ‑‑b-pyramid -r 10 ‑‑analyse=all ‑‑direct auto ‑‑weightb ‑‑me umh ‑‑subme=7 ‑‑b-rdo ‑‑bime -8 -t 1
44.	-b 4 ‑‑b-pyramid -r 10 ‑‑direct auto ‑‑weightb ‑‑me umh ‑‑subme=7 ‑‑b-rdo ‑‑bime -8
45.	-b 3 ‑‑b-bias 5 ‑‑b-pyramid ‑‑weightb ‑‑b-rdo ‑‑subme=6 ‑‑bime ‑‑pass 1 -b 3 ‑‑b-bias 5 ‑‑b-pyramid ‑‑weightb ‑‑b-rdo ‑‑subme=6 ‑‑bime ‑‑pass 2
46.	-b 4 ‑‑b-pyramid -r 8 ‑‑analyse=all ‑‑direct auto ‑‑weightb ‑‑me umh ‑‑subme 7 ‑‑b-rdo ‑‑bime -8 ‑‑pass 1 -b 4 ‑‑b-pyramid -r 8 ‑‑analyse=all ‑‑direct auto ‑‑weightb ‑‑me umh ‑‑subme 7 ‑‑b-rdo ‑‑bime -8 ‑‑pass 2