[Ffmpeg-devel] [REQUEST] MMX/MMX2 and SSE optimizations for H.264 decoding

Corey Hickey bugfood-ml
Wed Sep 14 22:08:34 CEST 2005

M?ns Rullg?rd wrote:
> Guillaume POIRIER said:
>>If your CPU is too slow, too bad for you. H.264 is a very hungry
>>codec. You can, however, disable some "eye candy" routines at decode
>>time like the inloop filter or things like that. MPlayer allows you to
>>control this with the option "-lavdopts" if I'm not mistaken (read the
>>man page).
> Disabling the loop filter is not a good idea.  The encoder uses filtered
> pictures for prediction.  That's why it's called inloop filter.  By disabling
> it during decoding, you'd be using incorrect reference data for predicted
> blocks, which might get ugly.

It might get ugly, but it might not. I haven't tested extensively, but
with what I've seen the differences only become apparent in videos or
parts of a video where there isn't enough data to encode the picture
precisely. For a well-encoded video, you shouldn't notice any difference
unless you look really closely. Disabling the inloop filter is worth it
for playing a file that wouldn't be playable otherwise.

Also, you can choose to only disable the filter for frames that aren't
used for predication. This still makes a significant difference in CPU
usage, and allows me to play the biggest h264 video I know of:


Here are some quick benchmarks for:
mplayer -nosound -vo null -benchmark bbc_1080p.mov
(with various -lavdopts skiploopfilter= options appended)

I have an athlon64 clocked at 2543 MHz. The video is 93.2 seconds long.

BENCHMARKs: VC:  78.955s VO:  0.005s A:  0.000s Sys:  0.594s =  79.554s

BENCHMARKs: VC:  64.640s VO:  0.005s A:  0.000s Sys:  0.371s =  65.016s

BENCHMARKs: VC:  64.492s VO:  0.005s A:  0.000s Sys:  0.371s =  64.869s

BENCHMARKs: VC:  49.174s VO:  0.005s A:  0.000s Sys:  0.366s =  49.546s

BENCHMARKs: VC:  48.239s VO:  0.005s A:  0.000s Sys:  0.368s =  48.612s


More information about the ffmpeg-devel mailing list