[Top][All Lists]

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

Re: [Ccrtp-devel] problem while reducing the seding rate

From: Dinil Divakaran
Subject: Re: [Ccrtp-devel] problem while reducing the seding rate
Date: Fri, 13 May 2005 08:26:26 +0530 (IST)

Sorry, I didn't mean the variable bit rate codecs. My doubt is
regarding any kind of data (audio, video etc).

Suppose we are using something like below:


then, the program sends only 3 packets. Whereas, if the above
statement is changed to


the program sends some 30+ packets.

Now, when I am writing a program to send data (be it of any
kind), I may use the program to send 1 MB of data or even
50 MB of data; so to what value should the expire timeout
be set ?

I hope, I have made myself clear this time around :)

I assume the value given to setExpireTimeout is in microseconds;
else please correct me.

- Dinil

On Thu, 12 May 2005, Michel de Boer wrote:

Why in the first place do you want to transmit the data at
a different speed? What codec do you use for the audio?

I have only experience with G.711 and GSM encoded audiostreams.
These codecs have a constant bit rate, eg. G.711 has 160 bytes/20ms,
GSM has 33 bytes/20ms So I have to make sure to send the audio streams
with these speeds. I just set the correct payload type with
setPayloadFormat and it all works fine as long as I deliver the
data at the correct rate to ccRTP.

I am not sure how RTP works with variable bit rate codecs.

Dinil Divakaran wrote:

For the time being I fixed sending 2833 events as follows:

    rtp_session->setExpireTimeout(duration of event)

This way the packets stay within the oldness check in ccRTP.

But, we can not give a static argument to setExpireTimeout since
the number of packets change depending on the data that has to
be transmitted. Hence, if the value set by setExpireTimeout is
okay for a 1 MB data, it need not be useful for sending data
larger than 1 MB. This happens since the packets do not stay
within the oldness check as the number of packets increase.

David Sugar wrote:

Oh, this is about sending 2833 events, not receiving...sorry :). Hmm, let me think about this one further!

reply via email to

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