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

[Nick Kurshev]

Hello, Michael!

On Mon, 25 Feb 2002 15:54:09 +0100 you wrote:

> Hi
> 
> On Monday 25 February 2002 08:24, Nick Kurshev wrote:
> [...]
> > 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
> imho, vo-drivers should allocate the buffers, they might even be in video mem 
> then
> perhaps something like
> 
> get_surface()/free_surface()
> implemented in each vo, and if its not supported then simply returning NULL 
> (the libvo-core could then use a normal malloc() based buffer)
> draw_frame / draw_slice could then be moved into the libvo-core
> flip_page(vo2_surface_t *surface) which flips the page if possible or memcpy 
> it if not
> 
1. As I already said - ATI's card don't have vertical synchroniszation async event
(as matrox) finely - I don't have doumentation for that.
2. So wait_vsync causes unnecessary delays, but buffer switching without them
causes juderring.
3. Working with RAM is just generic solution. Indeed it would be possible
move onto video memory in the future but not for now.
4. Video memory is expensively of RAM.
> [...]
> 
> Michael
> 
> PS: the decoding ahead thing was just an idea, i didnt seriously expect it to 
> be done ...
Why - not?
At least I started that and it doesn't affect stability due #ifdefed code ;)

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