[Ccrtp-devel] ccRTP modifications

[Yaniv Levy]

Hello,

While using ccRTP for a RTP relay and media processing software I tweaked ccRTP to fit my needs.
I think that some of the changes will be needed by others using ccRTP, so I am describing them.
I'm using RTSP as a signalling protocol. My application listens to a packets coming from a streaming
server and, performs media processing and relays the packets to a player over RTP. 

(1) Setting of RTCP interval. 
It had a method decleration but no implementation.  
diff -r ccrtp-1.3.6/src/ccrtp/cqueue.h original/ccrtp-
1.3.6/src/ccrtp/cqueue.h
162,163c162
<     setMinRTCPInterval(microtimeout_t interval) 
<     { rtcpMinInterval = interval; }
---
>     setMinRTCPInterval(microtimeout_t);

(2) RTSP related: 

When implementing RTSP PLAY command, the sender (my application) response must tell the receiver (player) what  will be the
epoch timestamp and sequential number of the stream.
The application must have a method to ask/tell ccRTP what will be this value for the outgoing stream, hence getCurrentSeqNum()
and setInitialSeqNum().


diff -r ccrtp-1.3.6/src/ccrtp/oqueue.h original/ccrtp-1.3.6/src/ccrtp/oqueue.h
352,357c352
<     inline void
<     setInitialSeqNum(uint32 seqNum) 
<         { sendInfo.sendSeq
 = seqNum; }
<     inline uint32
<     getCurrentSeqNum(void) 
<         { return sendInfo.sendSeq; }
---
> 

(3) RTSP related: the problem of PLAY-PAUSE-PLAY sequence

There is a hidden assumption in ccRTP that the first received packet carries data to be played at time zero.
This is usually true when asking a streaming server to play form the beginning of the media file.
But, In the case of seek(*) to a randon place in the file, the streaming server will wait until it encounters a video I-frame.
In this case, the first packet that arrives to ccRTP carries data that should be played at several millisecseconds after zero time.

(*) in RTSP, seek is implemented as PAUSE and PLAY (with media time value)


When creating an RTPSession object for listening purposes, it will listen on the designated port, and wait for the first packet to arrive.
This first packet's sequentinal number sets the initial timestamp of this SSRC stream. All packet's timestamp passed to application are substructed by this value,
so the application gets a stream of packets stating always at zero timestamp.

However, on a PLAY-PAUSE-PLAY RTSP sequence, the PAUSE tells the application not to use incoming packets and packet in input queue,
and the second PLAY tells to use this stream again, starting at different sequence and timestamp epoch.
ccRTP handles gracefully a new sequence of packet numbers, but it keeps substructing the old initial timestamp and this is errornoues.

I choose to deal with this by asking ccRTP not to setInitialDataTimestamp to first packet's timestamp but to zero.

In RTSP, A response to play command is the epoch timestamp and sequence number. When my application gets this responcse, it knows 
(i) to dump all packets perior to this epoch sequence number.
(ii) to substruct the epoch timestamp from all packets to get the "playing" timestamp.


diff -r ccrtp-1.3.6/src/incqueue.cpp original/ccrtp-
1.3.6/src/incqueue.cpp
673,674c671

<             srcLink.setInitialDataTimestamp(0);
---
>             srcLink.setInitialDataTimestamp(pkt.getTimestamp());

A more general approach could be the ability to set epoch time stamp of the incoming stream from the application. 
this is tricky: upon issuing PLAY to the transmitter, two things happens which race their order: the arrival of packet stream, and the PLAY response with epoch values.RTP receiver must recieve packets, although it may not know yet the epoch values.

Best regrds,
Yaniv Levy