gnash-dev
[Top][All Lists]
Advanced

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

[Gnash-dev] Re: FLVParser bugs


From: Tomas Groth
Subject: [Gnash-dev] Re: FLVParser bugs
Date: Mon, 4 Jun 2007 12:47:40 +0200 (CEST)

--- strk <address@hidden> skrev:

> 
> I've found out that the FLVParser::nextVideoFrame and
> FLVParser::nextAudioFrame 
> don't do whaat their description states, which is causing lots of troubles.
> 
> Their description says that they return NULL if NO MORE FRAMES are in the
> timeline.
> Example (for nextVideoFrame):
> 
>         /// Returns the next video frame in the timeline. If no frame has
> been
>         /// played before the first frame is returned. If there is no more
> frames
>         /// in the timeline NULL is returned.
> 
> Now, the implementation doesn't do that. In particular, it makes use of the 
> FLVParser::parseNextFrame() which isn't a blocking call at all, and breaks
> it's "blocking" loop if that returns false.
>
> parseNextFrame will return false if we did NOT load enough data, so the
> result is that next{Audio,Video}Frame will also return NULL in this case,
> reguardless of having reached EOF.
> 

I don't agree... FLVParser::parseNextFrame() shouldn't be blocking, since every
function that uses it is blocking (and if they're not then that is a bug). Also
I guess the definition of "timeline" is the issue here, since the timeline in
the comment is defined as being the *known* FLV timeline, which means the
timeline we know exist in the parsed data, which is the same situation whether
we're slow at loading data, or we've reached EOF. To know the differens we can
use _parsingClomplete in FLVParser, or NetConnection::loadCompleted().

cheers,

Tomas


      




reply via email to

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