[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 1.5.0.4 (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
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel
dyfet.vcf
Description: Vcard