[MPlayer-dev-eng] DECODING AHEAD - (Initialy Michael's idea)

[D Richard Felker III]

On Tue, Feb 26, 2002 at 10:25:58AM +0300, Nick Kurshev wrote:
> > your new idea will help performance on systems that are basically fast
> > enough to play the movie, but that need a little extra cpu time for
> > super-intensive frames every now and then. it will not help in the
> > slightest on computers where mplayer is never sleeping and is at 100%
> > cpu usage all the time. further, it will not even help in the
> Yes! My idea requires to have sometime less of 100% cpu usage.
> Otherwise - it doesn't matter which algorithm will drop frames ;)

Then what on earth is the point? If the machine is already fast enough
there's no reason to optimize further only for that machine.
Optimizations only make sense when they benefit machines that aren't
yet fast enough/

> > as examples, consider a couple scenes from the matrix divx. zooming
> > through the 0 at the very beginning and the helicopter explosion scene
> > were both too slow for my k6-2/450 to handle (without framedrop) until
> > recently. since pretty much all the rest of the movie was a plenty
> Matrix contain I,P-frames between B-frames anyway

I said DIVX, not DVD. Playing DVDs is so fast with the overoptimized
libmpeg2 its not even funny. As far as I know, no one encodes DIVX
with B frames or such silliness; I don't even know if they're
supported.

> > fast, buffering should have been able to fix this -- but buffering a
> > measly 8 frames would have made no difference whatsoever; it would
> > take at least a second worth of buffering or so.
> > 
> > the second moral of this example is that the problem *was fixed* in
> > the correct way: optimizing the codec and other parts of mplayer. and
> > this is still without direct rendering.
> > 
> Why you need direct rendering?
> Direct rendering is usefull for current mplayer.
> If I wil be able to finish my idea there will be direct rendering too
> but only through fastmemcpy already decoded frames in memory.

Because it's the only way to overcome the single biggest performance
bottleneck -- memory bandwidth! Actually because of other
optimizations, I don't really need it for much myself at this point,
but I bet someone with a k6-2/333 instead of my 450 would appreciate
it a lot!

> > the biggest key to performance at this point is getting direct
> > rendering working with libavcodec (and other codecs) and other video
> > out modules (mga, xmga) as opposed to just vidix. buffering may be
> > able to help, but only at the expense of tons of memory.
> You are wrong! Direct rendering can't be imlemented anywere except vidix.
> But it already works with all working drivers.

Yes it can. There is no reason it cannot be implemented with mga and
xmga.

> What about libavcodec - it requires to be rewritten to implement
> direct rendering with its codecs.
> And even in this case I don't get 50% of speedup.

Buffering will not give you a 50% speedup either.

> direct rendering gives only 10-20% of speedup. Where you found out "huge"?

Thank you for supporting my point. 20% is huge. Most individual
optimizations give 1-5% speedup tops.

Rich