[Live-devel] pause issue

[Gilles Chanteperdrix]

On Mon, Feb 23, 2015 at 09:42:04PM +1300, Ross Finlayson wrote:
> No, I don???t want to make any change that???s just going to
> ???paper over??? the real problem;

That is fine by me, but it seems to me you will have a hard time
doing that (unless using the play time as presentation time along
the pipe, but that would be a big change).

> the existing code is correct, 
> and works just fine for its intended purpose.

It seems to me the code is not correct when using pause, but indeed,
my code could be the culprit.

> 
> It???ll be better to definitively identify exactly if/when/how old data (with old presentation times) is being transmitted when we resume from a ???pause???, and to fix the code to prevent that from happening.  That???d be the real bug.

I have identified one condition when it happens: if pause is
triggered when a MultiFramedRTPSink has some overflow data. When
restarting from pause, MultiFramedRTPSink will use the saved
presentation time which dates back from before the time of the
pause, so is clearly in the past. And even if MultiFramedRTPSink is
fixed for that, a framer or filter earlier in the pipeline can do
the same (reuse a presentation time it saved).

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 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();
    }
  }


-- 
					    Gilles.