gnash-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-commit] gnash ChangeLog libbase/FLVParser.h server/asob...


From: Sandro Santilli
Subject: Re: [Gnash-commit] gnash ChangeLog libbase/FLVParser.h server/asob...
Date: Wed, 30 May 2007 15:03:34 +0200

More info, it seems this behaviour is correct except for the 
excessive wait before going on with the playback.
Gnash waits for the buffer to contain at least 20 frames
while this wait is superfluos. In Gnash frames > 20 is the
only condition in which the lock is released thus allowing
::advance to do it's job..

--strk;

On Wed, May 30, 2007 at 02:53:28PM +0200, Sandro Santilli wrote:
> On Wed, May 30, 2007 at 12:48:22PM +0000, Sandro Santilli wrote:
> 
> > Log message:
> >             * libbase/FLVParser.h: document timestamp units for media frames
> >               and isTimeLoaded().
> >             * server/asobj/NetStreamFfmpeg.{cpp,h}: document units for time
> >               members; (advance): fix isTimeLoaded() call, thanks Martin Guy
> >               for noticing.
> 
> Alright, with this fix the playback behaviour is much cleaner.
> Right now, it goes like this:
> 
>       - Fill the buffer up to a given amount
>       - Play flushing the buffer
> 
> The above two steps are repeated till the full movie is loaded.
> It is clear to me that the problem is that the buffer is not being
> filled *while* the flushed...
> 
> This is most likely due to the *filler* (av_streamer) locking the 
> mutex and only releasing (by waiting on a condition) when the buffer
> contains at least 10 frames.
> 
> Rather, the *filler* should run continuosly w/out locking any mutex
> unless actually accessing the buffer (ie: no locking if new frames are
> not available, or not wanted).
> 
> Does it sound ?
> 
> --strk;

-- 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]