How various x264 encoding options affect Decoding CPU usage.

[AnonCrow]

Disclaimer: Don't take the numbers literally and start drawing graphs,
only meant as general ballpark figures.

Mostly used Mplayer -benchmark -vo null ,
no videos had sound. VC times listed
Video sources: 720p mp4 (~2Mbps) downloads from youtube (Pink - Sober) ,
apple.com/trailers, virtualdub (3:2 pulldown test video)


Hardware for decoding:

850 MHz Mobile P-III , 100MHz FSB, W2K , 256 MB RAM, Ati Mobility M4 32MB

Cabac, bitrate and resolution:


Source length 125 seconds, deblock=0, 2 pass, 24 fps.

pixels
a=368x208 = 76544
b=512x288 = 147456 +92,6%
c=720x400 = 288000 +95.3%
d=1280x720= 921600 +220% (3.20)

Cabac=0, 512Kb

a 10
b 16.3 +63%
c 28.2 +73%
d 74.3 +163%


Cabac=1, 512Kb

a 12.8
b 20 +56%
c 33.7 +68.5%
d 87.8 +161%



Cabac=0, 2048Kb

a 15.6
b 24.1 +54%
c 38.1 +58%
d 90.5 +138%


Cabac=1, 2048Kb

a 22.1
b 32.9 +48.9%
c 48.8 +48.3%
d 111.3 +128%



cabac=0, 512k vs. 2048k

a +56%
b +47,9%
c +35.1%
d +21.8%


cabac=1, 512k vs. 2048k

a +72.7%
b +64.5%
c +44.8%
d +26.8%



720p , Cabac=0

256k 69.5
512k 74.3 +6.9%
2048k 90.5 +22%
8192k 128.1 +41%


720p , Cabac=1

256k 81.1
512k 87.8 +8.2%
2048k 111.3 +26.8%
8192k 170.7 +53.4%


720p, fixed bitrate, cabac 0 vs 1 (from the two sets above)

256k +16.7%
512k +18.2%
2048k +23,0%
8192k +33.3%





Deblocking, Number of reference frames, bframes, all the little settings

Source: 720x400 , 2 pass 256 kbps, 25 fps , 260 sec

deblock

0 49.3
1:0:0 72.2
1:2:2 72.5
1:-2:-2 72.3


ref
frames:

0 48.56
1 48.61
2 48.95
3 49.29
4 49.40
6 49.69
8 49.94
16 50.42


bframes=x , b_adapt=1

VC I P B
1 45.30 195, 4673, 1649
2 48.32 195, 4163, 2159
3 48.95 195, 3919, 2403
4 49.99 195, 3766, 2556

bpyramid,weightb,allpartitions and mbtree disabled: 45.30
Like above but mbtree enabled: 44.87
Mbtree disabled, others enabled: 45.30



ME type and range

720x400, 2 pass 512 kbps (actual 504-505), 25 fps , 260 sec

dia 8 53.95
dia 16 54.26
hex 8 54.06
hex 16 54.44

umh 16 54.69
umh 32 54.58
umh 48 54.82

esa 16 51.84
esa 32 51.92
esa 48 51.90

tesa 16 51.80
tesa 32 51.89
tesa 48 51.72




Subme

1024x576 , crf=25 , 25 fps , cabac=0 , deblock=0, bframes=4, b_adapt=1
source length: 260 sec , encoded length 259 - 260 sec.

subme VC AVG bitrate
0 104.67 767
1 113.53 740
2 112.31 735
3 114.65 757
4 114.54 752
5 115.04 747
6 120.98 689
7 118.69 708
8 120.8 716
9 120.45 717



Same as above but 2 pass 512kbps

VC

0 97.74
1 107.78
2 105.85
3 109.59
4 108.07
5 108.58
6 116.58
7 115.70
8 117.40
9 117.56

avg bitrate for all 504

for the 2 pass, decoding times for timecodec null & VMR9, VLC (1.0.1pre) and 'mplayer -benchmark' (VC+VO+SYS, total), respectively:

subme 0: 128 , 178 , 222 , 96+31.5+3.1~130.75
subme 5: 136 , 188 , 228 , 107+31.4+3.2~141.70
subme 9: 145 , 199 , 240 , 116+31.6+3.1~150.90



Trellis and AQ, subme=9|10, practically irrelevant

1024x576 , 2 pass 512 kbps , 25 fps , 260 sec
subme=6,

trellis=0 , aq=0 116.98
trellis=0 , aq=1 116.73
trellis=0 , aq=2 116.04
trellis=1 , aq=2 116,02
trellis=2 , aq=0 118.55
trellis=2 , aq=1 116.93
trellis=2 , aq=2 116.25


trellis=2, aq=2:
subme=9 116.79
subme=10 117.27




X264 vs. MPEG2 vs XVID

source 120 sec 720P

MPUI+mplayer cpu times:

mpeg2 24fps 2Mbps : 66s
mpeg2 24fps 4Mbps : 77s
xvid HQ 24fps 2Mbps : 82s
x264 12fps cabac=0, deblock=0 2Mbps : 59s
x264 12fps cabac=1 deblock=1 1280kbps : 94s

VLC playing 60 sec of the above (played back at 2/3 speed)

mpeg2 2M :55s
mpeg2 4M :60s
xvid 2M :67s
x264C0 2M :46s
x264C1 1280kb :64s



Yes yes, would've been more readable on eg google docs.
Encoders used : x264 r121x / r122x

[juGGaKNot]

so umh with subme 10 and 16 refs is faster to decode than umh with subme 7 and 3 refs for ex ?

[AnonCrow]

so umh with subme 10 and 16 refs is faster to decode than umh with subme 7 and 3 refs for ex ?

The other way around, subme=7 & 3 refs should decode about 2 - 3 % faster than subme=10 & 16 refs.
However, if subme7 was umh but subme10 was esa, then the favor would turn around.

[juGGaKNot]

umh 16 54.69 subme 10 117.27
esa 16 51.84 subme 7 115.70

1 = ~172
2 = ~167

seconds ?

[AnonCrow]

umh 16 54.69 subme 10 117.27
esa 16 51.84 subme 7 115.70

1 = ~172
2 = ~167

seconds ?

Correct , seconds spent in VC as reported by mplayer -benchmark -vo null.

Note that the subme=0-9 encodes were encoded without trellis and aq, while subme=9|10 with them, though that shouldn't increase subme=7 by more than a second.

Even a difference of a couple percent in decoding speeds is so small that it could easily go either way depending on the quality and type of the source (lossy youtube vid vs. lossless vdub test video).

[akupenguin]

You can't compare speeds at equal bitrate, because bits cost time too. (http://forum.doom9.org/showthread.php?p=1298467#post1298467) CRF or CQP don't cut it either, except in the very specific case of comparing cabac to cavlc without rdo. The only correct comparison is holding some distortion metric constant (which will involve several encodes of each setting to tweak the target bitrate or CRF, since x264 doesn't have a target distortion metric mode).

Also, if you get significantly different times between MPlayer and VLC, you're doing something wrong.

[AnonCrow]

Also, if you get significantly different times between MPlayer and VLC, you're doing something wrong.

Pondered that as well, that was likely due to the version of VLC used (1.0.1pre); different versions (stable 0.9.9 and 1.0.0, 1.1.0pre) got times as much as 20-30 % less
at times. The fact the CPU time used by VLC was taken
from plain ol' windows task manager played it's part too.

[benwaggoner]

This looks about what we'd expect. CABAC and in-loop deblocking are the most expensive features, with the other parameters having less total impact. It's interesting to see that the strength of the loop filter doesn't have much impact.

As akupenguin suggests, we shouldn't assume that there's a net negative performance with the more expensive encoder features, since at the same efficiency metric, they may have equivalent complexity. A more efficient encoder that's able to find more useful motion vectors will result in higher quality output, but will be somewhat harder to decode as well. So comparing at the same quality should have similar complexity, and we'll just have smaller files with the same quality and decode complexity of a less efficient encode at a higher bitrate (which is a good thing).

Another thing to consider in performnce is speed of random access, not just straight play-through. That's where multiref and b-frame patterns can have a big impact (potentially a positive ones). For that you'd want to measure time to present particular frames.

[akupenguin]

Multiref doesn't affect which frames you have to decode when seeking, and thus doesn't have any speed impact separate from its impact on linear decoding. The extra refs only point to previous nondisposable frames, which are ones you can't skip anyway.