[MPlayer-dev-eng] DECODING AHEAD - (Initialy Michael's idea)
nickols_k at mail.ru
Tue Feb 26 08:25:58 CET 2002
On Mon, 25 Feb 2002 19:36:12 -0500 you wrote:
> 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
Yes! My idea requires to have sometime less of 100% cpu usage.
Otherwise - it doesn't matter which algorithm will drop frames ;)
> "occasional intensive scene" case, unless there are *tons* of buffers
> (like 100+) or else the intense stuff is very short.
If your movie consists from B-frames only then - yes!
Could you imagine self such situation?
If you have running 25 B-frames then you should watch 25 different scenes
during 1 sec. In this case losing frame doesn't matter, imho.
More information about the MPlayer-dev-eng