[Live-devel] pause issue

[Gilles Chanteperdrix]

On Tue, Feb 24, 2015 at 08:07:15AM +0100, Gilles Chanteperdrix wrote:
> On Tue, Feb 24, 2015 at 07:37:59PM +1300, Ross Finlayson wrote:
> > 
> > > On Feb 24, 2015, at 7:27 PM, Gilles Chanteperdrix <gilles.chanteperdrix at xenomai.org> wrote:
> > > 
> > > On Mon, Feb 23, 2015 at 11:03:24AM +0100, Gilles Chanteperdrix wrote:
> > >>  in the following
> > >> sequence of OnDemandServerMediaSubsession.cpp:
> > >> 
> > >> 
> > >>  if (streamState != NULL) {
> > >>    streamState->startPlaying(destinations,
> > >> 			      rtcpRRHandler, rtcpRRHandlerClientData,
> > >> 			      serverRequestAlternativeByteHandler, serverRequestAlternativeByteHandlerClientData);
> > >>    RTPSink* rtpSink = streamState->rtpSink(); // alias
> > >>    if (rtpSink != NULL) {
> > >>      rtpSeqNum = rtpSink->currentSeqNo();
> > >>      rtpTimestamp = rtpSink->presetNextTimestamp();
> > >>    }
> > >>  }
> > > 
> > > The following patch avoids this issue:
> > 
> > What ‘issue'??  Previously you said there was no ‘issue’ - i.e.:
> 
> Sorry, what I meant is that this issue does not cause any side
> effect on the timestamps references (since the new reference is set
> after this packet sent immediately), so it has no lasting effect,
> but the issue here is that the RTP timestamps are wrong after a
> pause (they use the reference from before the pause).

Not all the RTP timestamps. Just the RTP timestamps of the packet sent
immediately by MultiFramedRTPSink::continuePlaying.


> > (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.

-- 
					    Gilles.