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

[Alban Bedel]

Hi Nick Kurshev,

on Mon, 25 Feb 2002 10:24:29 +0300 you wrote:

> Hello!
> 
> After discussing in mplayer-users my problem with interruptible playback
> there was born briliant idea about SUBJ!
> I didn't find this in libmpcodec planes.
> 
> Indeed, what we have currently?
> We have the fact when decoding of some frames (mainly P,I) requires
> much less of CPU usage than B-frames!
> IDEA: redistribute decoding of B-frames between decoding of I-frames
> to always have smooth and realtime playback.
> In this case MAX BENCHMARK will be useless and only AVE BENCHMARK
> will be significand.
> HOWTO: mplayer always should decode into RAM. There should be allocated
> some buffers (8 will be enough, I guess). after decoding of frame
> mplayer should start decoding of the next frame immediatedly, without any delays.
> mplayer shouldn't call libo->draw_slice function from self.
> Fortunately, linux support real-priority timer's callback. (in Win32 such
> thing is called multimedia timer). We can program timer callback
> as 1/vo_fps and our routine will call libvo->draw_slice.
> (FIFO technology).
> If we take hypothetical stream 2048x2048 at 32 then its frame requires 16MB
> in memory, so 10 frame buffer will require "only" 160MB + 20-30MB for audio.
> MINUSES: This technique requires full rewriting of A-V sync stuff and many
> other things. (I would say: it requires new CORE for mplayer)
> PLUSES: Direct rendering will be die :)
> It will born perfectly new mplayer with new CORE and new possibility.
> mplayer will become top smoothly player in the world. (But I suspect
> that many commercial players already have implemented such technology
> that caused smooth playback many movies even on not powerful cpus).
> 
> Best regards! Nick

I had a such idea some month ago, having a video cache  to use the time we won 
on frames easy to decode on frames hard to decode. 
A part of my idea was that we can save memory if the codec only output the 
part of the frame wich must be updated. But afaik none of the codec used
in mplayer do this :(
If possible we should avoid keeping decompressed audio, that's imho a real 
memory waste compared to what it give.
Finnaly we can perhaps keep the actual AV sync if we keep the var it use with each
frame in the cache. It's nothing in term of memory usage and could save a lot of
work.
I like to see something like this in mplayer because I'm sure that if it's well done my
K6-2 333 will be able to play 720x400 at 25 fps MPEG4 :))))
	Albeu