[Live-devel] pause issue

[Gilles Chanteperdrix]

On Tue, Feb 24, 2015 at 09:03:48PM +1300, Ross Finlayson wrote:
> >>> (I *do*, however, plan to fix the problem (that you noted) with
> >>> old data being sent (after resuming from a “PAUSE”) because of
> >>> it having been stored in ‘overflow data’  - once I’ve verified
> >>> this.)
> > 
> > The problem is not only with overflow data. It is a problem with any
> > framer or filter which stores presentation time and answer multiple
> > calls to doGetNextFrame with the same presentation time. Because one
> > call to doGetNextFrame may be before a pause, and the next after a
> > pause. H264or5Fragmenter does that for instance, independently from
> > MultiFramedRTPSInk overflow data.
> 
> Any data source object that wishes to implement pausing *might* need to reimplement the “doStopGettingFrames()” virtual function (which gets called - by the server - when it receives the RTSP “PAUSE” command).  It might need to do this in order to ensure that no extra data gets delivered after the pause.
> 
> If you haven’t already done so, you should think about whether you need to reimplement “doStopGettingFrames()” in your input source class (i.e., in your subclass of “FramedSource”).
> 
> Many of the existing LIVE555 source classes already reimplement "doStopGettingFrames()”.  It’s possible that there are others (that I’ve missed) that also need to reimplement "doStopGettingFrames()”.
> 
> But please don’t respond again unless you can identify a specific, verifiable bug (not just 
> ‘speculation’) in the existing (unmodified) code.

Again: the problem is not in the sources, yes, I have implemented
doStopGettingFrames in the source I implemented, but in the framers,
filters and rtp sinks. Please look at H264or5VideoRTPSink, and see
what happens when two calls to doGetNextFrame are separated by a
pause with the second call sending buffered data without calling the
source getNextFrame. I am not making any speculation, I am giving
you precise references to live555 code.

-- 
					    Gilles.