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

[Nick Kurshev]

Hello, Alban!

On Mon, 25 Feb 2002 10:32:03 +0100 you wrote:

> 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 :(
divxds outputs slices with direct rendering.
I found out that with -nodouble + OSD. OSD never repainted until next B-frame.
> If possible we should avoid keeping decompressed audio, that's imho a real 
> memory waste compared to what it give.
In this case A-V sync is hardly implemented
> 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 :))))
Duron-700 bench for 720x480 30fps MPEG4 (direct rendering):
AVE BENCHMARK%: V: 28.4434% VO:  0.0061% A:  1.7693% Sys: 69.7813% = 100.0000%
performance of Duron-700 vs K6-2/333 ~= 3 times if code+data are fitted in caches.
by socket bandwidth 15 times!
So I have doubts :(
In short: my old K6-200 was in 8-10 times slower of my new Duron-700.

Anyway - implementing of such changes requires losing of CVS stability (probably).
So Arpi should decide which way he preferes for mplayer in the future.
Maybe after release? Or maybe in the forked branch?
Anyway, it should be mplayer2, imho.

> 	Albeu


Best regards! Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20020225/39448e38/attachment.pgp>