[Live-devel] [PATCH 1/2] H264or5VideoStreamFramer: fix parsing logic

[Ross Finlayson]

> Right now H264or5VideoStreamParser can return 0 from parse() without
> requesting more data from input source which leads to frame
> delivery process becomes stalled (as MPEGVideoStreamFramer::continueReadProcessing()
> does not call afterGetting() in this case either).
> This can happen for several reasons:
>  1. Simply if input stream contains 2 or more consecutive start codes (AFAIK this
> should never happen in valid byte stream, but parser should not break if
> it happens).

OK, fair enough.


>  2. As a result of following sequence of events:
>    a. Parser reads all bytes prior to next start code, then gets
> interrupted because there is no more data available.
>    b. stopGettingFrames() gets called on framer and next frame is requested
> via getNextFrame(). This discards parsed data from previous frame and
> parser now assumes that it is reading new frame and thus already read
> start code.
>    c. Parser receives next bytes from input source which are the start
> code.
> 
> This patch moves start code parsing (and discarding) to the beginning of
> parsing current frame.

Right now I don’t see any justification for making just a drastic rearrangement of the existing code, which works well in almost all practical situations.  The situation (2.) that you describe - where stream reading resumes after a call to “stopGettingFrames()” - can be handled simply by defining the “doStopGettingFrames()” virtual function - in “H264or5VideoStreamFramer” - to call “flushInput()” in the parser, which will set the “fHaveSeenFirstStartCode” variable to False.  In that case, the right thing should happen if reading starts again later.

If I were to make just that change, then I don’t see the need to change anything else, except perhaps to handle the case of consecutive start codes (which isn’t a high priority, because - as you note - it shouldn’t happen in any valid byte stream).  But in any case that could be handled with just a minor change to the existing code.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150526/f3105877/attachment.html>