[MPlayer-dev-eng] DECODING AHEAD - preview

[Nick Kurshev]

Hello!

> 
> 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...
> 
As I said my patch can work only with vidix for now.
And it will work with other vo_drivers only after making them ready for
reenterability (it requires support for special voctrls).
> 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 ?
>
It highly loads cpu and I don't want to improve it anymore. 

> > 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).
> 
I have finaly fixed my "1st" patch. Now it works just fine without screen
juddering
and frame dropping. But it requires 4 video buffer at least.
So 'volatile' is far enough for my code and my thread doesn't require atomic
access (although it was untested by me on SMP but who said that it's final
point?).
But dec_ahead_locked_frame and dec_ahead_active_frame are only 
abbreviations and have nothing common with real locking/unlocking.
> -- 
> Best regards,
>   pl
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 

Best regards! Nick