ccRTP modifications

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

_______________________________________________
Ccrtp-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/ccrtp-devel