[MPlayer-dev-eng] DECODING AHEAD - preview

[pl]

Hi,

On Wed, Mar 13, 2002 at 01:52:47PM +0300, Nick Kurshev wrote:

> On Tue, 12 Mar 2002 12:28:11 +0100 you wrote:

> > 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.
> After implementing that it will be don't matter - what will call X11: thread
> or timer's callback. It suffered from non reenterability of X11.

Well... doing I/O from a signal handler is risky I'd say especially if
you interrupt another I/O function. Some library functions are thread
safe/reentrant but not signal safe...

If you are _sure_ all X11 calls are done from a unique thread then
that's OK.  Otherwise a lock has to be used on this library :/

> Your idea with timer's callback doesn't work - I can't take better than 40 ms
> resolution. So for realising of decoding ahead I've implement the same threads
> but in vosub_vidix stuff.
> 
> But my first version was better - simply because it didn't require emulation of
> high precision timer and could be run without root privelegies.
> The timeslice of thread didn't matter because thread performed decoding only
> and it always could be done realtimely.
> Indeed, 0x100 flags should be set only if there is real HW video timer.
> Currently my local version loads CPU at 100% with unnecessary loops of waiting
> of pts. Also it has a lot of negative sides like floating playback and so on.
> (Even using /dev/rtc requires thread in such case).

Maybe using a pthread_cond_t would help ?

> So I really don't understand your objections against of pthreads in mplayer's core.
> (they don't load cpu vs timer emulating and don't require root privelegies
> for realtime pleayback). Please think it again: if you want to solve concurent
> calls of X11 - it doesn't matter what they will call - thread or timer's callback.

Btw, Nick, you requested comments on your 1st patch (I quickly looked at
your diff so I might have missed something): volatile does not guarantee
you an atomic access (the generated asm code often confirms this :) and
you need to use mutexes to protect values (dec_ahead_locked_frame and
abs_dec_ahead_active_frame).

-- 
Best regards,
  pl