[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Re: FLVParser bugs
From: |
strk |
Subject: |
Re: [Gnash-dev] Re: FLVParser bugs |
Date: |
Mon, 4 Jun 2007 14:09:23 +0200 |
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;