[Live-devel] pause issue

[Gilles Chanteperdrix]

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

> 
> >> Another source of bad RTP timestamps (but which does not seem to
> >> cause any issue in live555) is when MultiFramedRTPSink starts
> >> sending packets immediately with (a correct presentation time or
> >> not) as a consequence of StreamState::startPlaying before
> >> RTPSInk::presetNextTimestamp has been called
> 
> I’m in no hurry to change any code that (in your words) “does not seem to cause any issue in live555”.  But in any case, wouldn’t the ‘solution’ be to simply move the call to “startPlaying()” after the “if” statement that contains the call to “presetNextTimestamp()”?

I have tried that, and it resulted in the loss of audio/video
synchronization. I have not looked deeper, but I would guess
startPlaying does more things than starting the rtpSink, which need
to be done before calling presetNextTimestamp(). If you are
interested, I can have a closer look.

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

It looks obvious to me, but I have spent my whole saturday trying to
understand why I could not get pause to work correctly. Note that I
have local changes that make it much more probable (as I already
explained on the list, I send the fragments of a large frame at a
limited bitrate, not as fast as possible, so the chance that an
RTPSink has overflow data when receiving a pause is much higher),
but I believe the bug exists in the unpatched live555, even if not
very probable.

-- 
					    Gilles.