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

[D Richard Felker III]

On Mon, Feb 25, 2002 at 10:36:39PM +0300, Nick Kurshev wrote:
> Hello, D!
> 
> On Mon, 25 Feb 2002 13:45:08 -0500 you wrote:
> 
> > On Mon, Feb 25, 2002 at 10:24:29AM +0300, Nick Kurshev wrote:
> > > PLUSES: Direct rendering will be die :)
> > 
> > what kinda crack are you smoking? direct rendering will be more of a
> > performance boost than buffering frames ahead could hope to be, once
> > its done. the only way i can see your idea being any good for
> direct rendering is my idea and first implementation
> When I did it then I knew what I'll get.
> Please believe me in this case we'll get much more!

i don't think you realize what a bottleneck memory bandwidth is,
especially on slower systems. it's absolutely huge.

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
"occasional intensive scene" case, unless there are *tons* of buffers
(like 100+) or else the intense stuff is very short.

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
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.

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.

finally, i would like to point out that some of the remarks and terms
in your original post on this matter just sounded idiotic. "FIFO
technology"? since when is a fifo technology? "Fortunately, linux
support real-priority timer's callback."? as many other people have
pointed out, this is probably a super brain-damaged way of doing
things. there's no need for it. i'm not even sure exactly what you
mean by that, but if you're talking about some kinda realtime
scheduling (which would need root), thats even stupider. and last but
not least, as i pointed out to begin with, "PLUSES: Direct rendering
will be die :)" is the ultimate accomplishment of crack smoking.
direct rendering is a huge performance benefit. with write combining
and agp 4x, the actual writes themselves are a ton faster than writes
to system memory, and can be carried out in parallel with system
memory access. that doesn't even begin to factor in the fact that,
without direct rendering, there's a whole extra copy operation to
perform! granted there are some issues with direct rendering (slow
reads from video memory and the like), and it may not be a good
solution for every codec out there, but it is nonetheless huge.

is that enough already??

rich