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

[Nick Kurshev]

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




-------------- 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/bf2642cb/attachment.pgp>