Re: [Gnash-dev] Re: FLVParser bugs

[strk]

On Mon, Jun 04, 2007 at 01:47:45PM +0200, strk wrote:
> On Mon, Jun 04, 2007 at 12:47:40PM +0200, Tomas Groth wrote:
> 
> > 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
> 
> Mmm.. I don't see why if callers are blocking it should not be, actually the 
> other
> way around would make more sense to me... The only way to make a non-blocking 
> call
> blocking would be sleeping and try again...
> Anyway, if it makes sense to you I'll just fix the comments and go on trying 
> to
> find out where the failure is (playback not started).

So, what I was tracking is decoder loop break conditions.
This is the point that triggered my journey into FLVParser:

NetStreamFfmpeg.cpp:647 (av_streamer):

        // If we have problems with decoding - break
        if (!ns->decodeFLVFrame() && ns->m_start_onbuffer == false && 
ns->m_qvideo.size() == 0 && ns->m_qaudio.size() == 0)
        {
                break;
        }

Now, decodeFLVFrame() is non-blocking, so might return false if no new data was 
loaded *yet*.
We surely don't want to exit the loop in that case, but just keep waiting until 
either the data
arrives or EOF is reached (that's were a blocking call would have done a better 
job).
Remember that this is the decoder thread, not the main thread, so blocking 
there won't hurt...

Anyway, a false return from decodeFLVFrame() is not enough to trigger the 
break, the code also
needs m_start_onbuffer being false and the decoded queues being empty. Sounds 
pretty complex to me.

Again, I would have the decoder loop only exit on ERROR or EOF.
Do you agree ?

--strk;