[Live-devel] Change Request about rtp timestamping when doing PAUSE/PLAY

[David BERTRAND]

Hi Ross,

As you maybe know, there is some ambiguity in RFC2326 about rtp timestamping when a sequence of PAUSE/PLAY messages occurs. I noted that live555 implementation for this consists of setting in the rtp-info header a rtptime value corresponding to the last RTP timestamp sent for this track (see testOnDemandRTSPServer for example). This probably works fine for some players but I personnaly made several tests with RealPlayer 10 and VLC 0.8.5 and none of those players are able to resynchronize the stream after the resume.
I tried to find out what would be the best behaviour of the library regarding this issue and it seems that a solution has been adopted by both draft RFC2326bis (draft-ietf-mmusic-rfc2326bis-13.txt) and 3GPP PSS specifications.

I must admit that I can't say that liveMedia's implemntation is buggy but as it is a very difficult issue that has been finally fixed by competent authorities, would you consider this as a valid Change Request ? I personnaly would appreciate a lot :-)
Thanks in advance for your feedback on this,
David

PS : Please find here below the section of rfc2326bis talking about this :

B.2.4 Handling RTP Timestamps after PAUSE

   During a PAUSE / PLAY interaction in an RTSP session, the duration of
   time for which the RTP transmission was halted MUST be reflected in
   the RTP timestamp of each RTP stream. The duration can be calculated
   for each RTP stream as the time elapsed from when the last RTP packet
   was sent before the PAUSE request was received and when the first RTP
   packet was sent after the subsequent PLAY request was received. The
   duration includes all latency incurred and processing time required
   to complete the request.


        The RTP RFC [18] states that: The RTP timestamp for each
        unit[packet] would be related to the wallclock time at
        which the unit becomes current on the virtual presentation
        timeline.

   In order to satisfy the requirements of [18], the RTP timestamp space
   needs to increase continuously with real time.  While this is not
   optimal for stored media, it is required for RTP and RTCP to function
   as intended. Using a continuous RTP timestamp space allows the same
   timestamp model for both stored and live media and allows better
   opportunity to integrate both types of media under a single control.

   As an example, assume a clock frequency of 8000 Hz, a packetization
   interval of 100 ms and an initial sequence number and timestamp of
   zero.


   C->S: PLAY rtsp://xyz/fizzle RTSP/2.0
         CSeq: 4
         Session: abcdefg
         Range: npt=10-15;

   S->C: RTSP/2.0 200 OK
         CSeq: 4
         Session: abcdefg
         Range: npt=10-15
         RTP-Info: url="rtsp://xyz/fizzle/audiotrack"
                   ssrc=0D12F123:seq=0;rtptime=0



   The ensuing RTP data stream is depicted below:


      S -> C: RTP packet - seq = 0, rtptime = 0,    NPT time = 10s
      S -> C: RTP packet - seq = 1, rtptime = 800,  NPT time = 10.1s
      S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
      S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s



   The client then sends a PAUSE request:


   C->S: PAUSE rtsp://xyz/fizzle RTSP/2.0
         CSeq: 5
         Session: abdcdefg

   S->C: RTSP/2.0 200 OK
         CSeq: 5
         Session: abcdefg
         Range: npt=10.4-15



   20 seconds elapse and then the client sends a PLAY request. In
   addition the server requires 15 ms to process the request:


   C->S: PLAY rtsp://xyz/fizzle RTSP/2.0
         CSeq: 6
         Session: abcdefg

   S->C: RTSP/2.0 200 OK
         CSeq: 6
         Session: abcdefg
         Range: npt=10.4-15
         RTP-Info: url="rtsp://xyz/fizzle/audiotrack"
                   ssrc=0D12F123:seq=4;rtptime=164400



   The ensuing RTP data stream is depicted below:

      S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
      S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
      S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s



   First, NPT 10 through 10.3 is played, then a PAUSE is received by the
   server. After 20 seconds a PLAY is received by the server which take
   15ms to process. The duration of time for which the session was
   paused is reflected in the RTP timestamp of the RTP packets sent
   after this PLAY request.

   A client can use the RTSP range header and RTP-Info header to map NPT
   time of a presentation with the RTP timestamp.

   Note: In RFC 2326 [28], this matter was not clearly defined and was
   misunderstood commonly. However for RTSP 2.0 it is expected that this
   will be handled correctly and no exception handling will be required.



-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze