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

[Corey Hickey]

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:

http://images.apple.com/movies/us/hd_gallery/gl1800/bbc_1080p.zip

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.

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

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

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

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

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


-Corey