13.07.2015 Views

Standards Track A. Rao Netscap - RFC Editor

Standards Track A. Rao Netscap - RFC Editor

Standards Track A. Rao Netscap - RFC Editor

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>RFC</strong> 2326 Real Time Streaming Protocol April 1998Appendix B: Interaction with RTPRTSP allows media clients to control selected, non-contiguoussections of media presentations, rendering those streams with an RTPmedia layer[24]. The media layer rendering the RTP stream should notbe affected by jumps in NPT. Thus, both RTP sequence numbers and RTPtimestamps MUST be continuous and monotonic across jumps of NPT.As an example, assume a clock frequency of 8000 Hz, a packetizationinterval of 100 ms and an initial sequence number and timestamp ofzero. First we play NPT 10 through 15, then skip ahead and play NPT18 through 20. The first segment is presented as RTP packets withsequence numbers 0 through 49 and timestamp 0 through 39,200. Thesecond segment consists of RTP packets with sequence number 50through 69, with timestamps 40,000 through 55,200.We cannot assume that the RTSP client can communicate with the RTPmedia agent, as the two may be independent processes. If the RTPtimestamp shows the same gap as the NPT, the media agent willassume that there is a pause in the presentation. If the jump inNPT is large enough, the RTP timestamp may roll over and the mediaagent may believe later packets to be duplicates of packets justplayed out.For certain datatypes, tight integration between the RTSP layer andthe RTP layer will be necessary. This by no means precludes theabove restriction. Combined RTSP/RTP media clients should use theRTP-Info field to determine whether incoming RTP packets were sentbefore or after a seek.For continuous audio, the server SHOULD set the RTP marker bit at thebeginning of serving a new PLAY request. This allows the client toperform playout delay adaptation.For scaling (see Section 12.34), RTP timestamps should correspond tothe playback timing. For example, when playing video recorded at 30frames/second at a scale of two and speed (Section 12.35) of one, theserver would drop every second frame to maintain and deliver videopackets with the normal timestamp spacing of 3,000 per frame, but NPTwould increase by 1/15 second for each video frame.The client can maintain a correct display of NPT by noting the RTPtimestamp value of the first packet arriving after repositioning. Thesequence parameter of the RTP-Info (Section 12.33) header providesthe first sequence number of the next segment.Schulzrinne, et. al. <strong>Standards</strong> <strong>Track</strong> [Page 79]

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!