[Live-devel] Filestreaming

Meding, Matthias m.meding at ids-imaging.de
Fri Sep 7 03:11:09 PDT 2012


Hi Ross,

 

thank you for your quick reply.

 

My second topic was (and still is):

 

>> On client-side I use the method "MediaSubsession::getNormalPlayTime".
All works fine for the first play-command. But after the send of a
second play-command the method returns wrong values with the receive of
a new RTCP "SR" packet. Whats going wrong?

 

> I don't know, because you haven't provided nearly enough information.
Do both the RTSP client and the RTSP server use our code, or just the
RTSP client?  Please provide the complete RTSP protocol exchange
(including both "PLAY" commands) between your client and your server, up
to the point at which you believe the call to "getNormalPlayTime()"
returns an incorrect result.

 

On both sides I use live555.

 

Protocol exchange (only client side):

 

1.) pRtspClient->sendPlayCommand(*m_pMediaSession, continueAfterPLAY,
0.0, -1.0, 1.0, m_pAuthenticator);

 

Sending Request: PLAY xxx

CSeq: xx

User-Agent: xx

Session: xxx

Range: npt=0.000-

 

Received a complete PLAY response

RTSP/1.0 200 OK

CSeq: xx

Date: xxx

Range: npt=0.000-

Session: xxx

RTP-Info: xxx

 

2.) pRtspClient->sendPauseCommand(*m_pMediaSession, continueAfterPAUSE,
m_pAuthenticator);

 

Sending Request: PAUSE xxx

CSeq: xx

User-Agent: xx

Session: xxx

 

Received a complete PAUSE response

RTSP/1.0 200 OK

CSeq: xx

Date: xxx

Session: xxx

 

------> all o.k.

 

3.) pRtspClient->sendPlayCommand(*m_pMediaSession, continueAfterPLAY,
-1.0, -1.0, 1.0, m_pAuthenticator);

 

Sending Request: PLAY xxx

CSeq: xx

User-Agent: xx

Session: xxx

Range: npt=0.000-

 

Received a complete PLAY response

RTSP/1.0 200 OK

CSeq: xx

Date: xxx

Range: npt=0.000-

Session: xxx

RTP-Info: xxx

 

------> all o.k. until a RTCP "SR" packet sets the rtpTimestamp in
"RTPReceptionStats::noteIncomingSR"

 

Example: (after second PLAY command)

...

 

presentationTime before NPT: 13469992513654

presentationTime after NPT:     10000000

 

presentationTime before NPT: 13469993513654

presentationTime after NPT:     1100000

 

presentationTime before NPT: 13469994513654

presentationTime after NPT:     1200000

 

presentationTime before NPT: 13469995513654

presentationTime after NPT:     1300000

 

...

 

new incoming "SR" packet ---> change the "fSyncTimestamp" in "
RTPReceptionStats::noteIncomingSR"

 

presentationTime before NPT: 13468215331451

presentationTime after NPT:     -123045

 

...

 

It seems that the "fNPT_PTS_Offset" in
"MediaSubsession::getNormalPlayTime" has a wrong value after the setting
of "fSyncTimestamp"!

 

double MediaSubsession::getNormalPlayTime(struct timeval const&
presentationTime) {

...

   if (rtpInfo.infoIsNew) {

      // This is the first time we've been called with a synchronized
presentation time since the "rtpInfo"

      // structure was last filled in.  Use this "presentationTime" to
compute "fNPT_PTS_Offset":

      if (seqNumLT(rtpSource()->curPacketRTPSeqNum(), rtpInfo.seqNum))
return -0.1; // sanity check; ignore old packets

      u_int32_t timestampOffset = rtpSource()->curPacketRTPTimestamp() -
rtpInfo.timestamp;

      double nptOffset =
(timestampOffset/(double)(rtpSource()->timestampFrequency()))*scale();

      double npt = playStartTime() + nptOffset;

      fNPT_PTS_Offset = npt - ptsDouble*scale();

      rtpInfo.infoIsNew = False; // for next time

 

      return npt;

    } else {

      // Use the precomputed "fNPT_PTS_Offset" to compute the NPT from
the PTS:

      if (fNPT_PTS_Offset == 0.0) return 0.0; // error: The "rtpInfo"
structure was apparently never filled in

      return (double)(ptsDouble*scale() + fNPT_PTS_Offset);

    }

...

 

If I change the expression from "if (rtpInfo.infoIsNew)" to "if (True)"
then "MediaSubsession::getNormalPlayTime" returns always the right
value.

 

Thanks in advance

 

Matthias Meding

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120907/14dff05a/attachment-0001.html>


More information about the live-devel mailing list