[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ccrtp-devel] ccRTP modifications

From: David Sugar
Subject: Re: [Ccrtp-devel] ccRTP modifications
Date: Mon, 24 Jul 2006 08:22:15 -0400
User-agent: Thunderbird (X11/20060614)

We should definitely add the missing method for setting RTCP interval.
Adding methods to get/set initial sequence number also can be useful, as
you note for RTSP based streaming.  I want to look more closely at the
effect of the third change.  This issue I think may also come up in
re-invite in SIP sessions.

Yaniv Levy wrote:
> 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
> address@hidden

Attachment: dyfet.vcf
Description: Vcard

reply via email to

[Prev in Thread] Current Thread [Next in Thread]