[MPlayer-dev-eng] DECODING AHEAD - preview

[Arpi]

Hi,

> I know there are other developers which work under the same problem.
> But it seems that my 'diff' is smaller. Anyway if someone can suggest
> something better - I'm ready forget about my branch and spend all my
> efforts to improve any other competited work.

> Any criticism, suggestion improvement are glagdly accepted.
> 
> Arpi, what do you thing about accepting this stuff?

you know well my optinion and objections against pthreads...
it's simply bad thing for mplayer - totally different design.

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
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.

I mean, for example vidix driver could set flag 0x100 at query_format,
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)

so, about this patch - it may go to /dev/null, but no to cvs...


A'rpi / Astral & ESP-team

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