Re: [Freevo-users] Help with benchmarking CPUs for HD decoding

[Jason T. <ta...@ur...>]

Hi Olivier,

On Tue, 2008-07-22 at 17:14 +0200, olivier arsac wrote:
> I have a problem though... I'm unable to get a run without dropping
> frames even on a 3.2GHz core 2 duo (penryn e8200 OC)
> If I disable sound output the test run smoothly... something fishy
> here.

If you disable sound, MPlayer does not need to maintain sync, and so it
decides not to drop any frames.


> frame drop test:
> $mplayer -fs cornell_m1080p.mov -lavdopts fast:skiploopfilter=nonref

The obvious thing here is that you're missing threads=2.  You want
-lavdopts fast:threads=2, and on that processor you can probably get
away with leaving out skiploopfilter=nonref.

That cornell video uses slices, so decoding can benefit from multiple
threads.  (Currently ffmpeg's h264 decoder parallelizes only at the
slice level.  Frame parallelization is coming.)

Most (perhaps all, at least all I've seen) Bluray and HD-DVD video uses
slices as well.  You can check if the content you're viewing has slices
by passing -lavdopts debug=1 -v.


> benchmark:
> real    0m34.380s
> user    0m47.687s
> sys    0m0.304s
> seems to have plenty of room for real time playback...

Yes, but the number of cycles needed to decode any given frame will
vary.  For example, in that video, the sequence around 70s is quite
demanding and will drop frames (at least on my E6600) without specifying
threads=2.

For single-sliced content, you're more likely to run into trouble.  I've
done a few test transcodes of 1080p Bluray content with x264 and at
crf=22 (with AQ) the bitrate was low enough to still manage without
dropped frames on a single core.  

In theory with a higher bitrate single-sliced h264 content you could
start dropping frames.  There we have two options: try
skiploopfilter=all (much more visible quality loss), or wait a few
months (hopefully just that!) for frame-level parallelization with h264
decoding.

Cheers,
Jason.