[MPlayer-dev-eng] DECODING AHEAD - preview

[Arpi]

Hi,

> > about the patch. it's surprisingly short, but seems to be messy
> > at some points. it just brings up a big question: qhy don't you
> > handle this mess at libvo level? it could work similar way to
> Because it was not hacked by me! Where this feature (0x100) was documented?

doch/tech/tech-eng.txt libvo section, flags

it was discussed a lot here, thanks to david holm...

> > hardware decoders (dxr3, dvb) - they already implement this
> > decoding ahead... mplayer decodes frames and push them to the
> > libvo/libao with timestamps, and they care to the right display
> > timing. so, if you want this mess, add a buffer switching code
> > (it could be really simple - just a few lines, and works even
> > with SIGALRM, no pthread required) to libvo drivers.
> why you against of pthread? This code was tested by me and works just fine!
you're lucky.

> (With vidix it doesn't affect non re-ent features of X11) 
it's the reason why it works at all

> > I mean, for example vidix driver could set flag 0x100 at query_format,
> Could you please publish full list of flags?
rtfm?

> > it means 'vo driver has own timers'. then mplayer will decoding
> > ahead, and your vo driver can set up a timer or thread to switch
> > between buffers at the right time. it's much cleaner way and solve
> > problem of not being thread-safe.
> > (and also eliminate problems with demuxer - your idea with sh_dup_ize
> > is dead - it is not possible to duplicate a demuxer, at least for
> > streaming formats)
> I already refused idea of dup_demuxer. This patch DOES WORK WITHOUT it.
> [snip]
> Well - I'll try your idea with timer's callback on libvo level.
ok

it can be even implemented to x11 only drivers - just needs some tricks to
mandatory lockout concurrent X calls from main 'thread' and timer handler.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu