<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">Right now H264or5VideoStreamParser can return 0 from parse() without<br class="">requesting more data from input source which leads to frame<br class="">delivery process becomes stalled (as MPEGVideoStreamFramer::continueReadProcessing()<br class="">does not call afterGetting() in this case either).<br class="">This can happen for several reasons:<br class=""> 1. Simply if input stream contains 2 or more consecutive start codes (AFAIK this<br class="">should never happen in valid byte stream, but parser should not break if<br class="">it happens).<br class=""></div></blockquote><div><br class=""></div>OK, fair enough.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""> 2. As a result of following sequence of events:<br class=""> a. Parser reads all bytes prior to next start code, then gets<br class="">interrupted because there is no more data available.<br class=""> b. stopGettingFrames() gets called on framer and next frame is requested<br class="">via getNextFrame(). This discards parsed data from previous frame and<br class="">parser now assumes that it is reading new frame and thus already read<br class="">start code.<br class=""> c. Parser receives next bytes from input source which are the start<br class="">code.<br class=""><br class="">This patch moves start code parsing (and discarding) to the beginning of<br class="">parsing current frame.</div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>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.</div><br class=""><br class=""><div apple-content-edited="true" class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Ross Finlayson<br class="">Live Networks, Inc.<br class=""><a href="http://www.live555.com/" class="">http://www.live555.com/</a></span></span>
</div>
<br class=""></body></html>