Subject: [AVT] Question on timestamp setting when multiple clock rates are used on the same stream

From: "zuo bf" <[email-masked]>
Date: Fri, 7 Jul 2006 16:51:13 +0800

Hi all,

      I am totally confused of how to set the timestamp if a stream is
negociated with some payload types of different clock rates,
I didn't find anywhere mention this or even whether it's allowed. But in
reality, if allowed we may use different clock rates at different
time or even the same time based on bandwith, user requirement or so on.
     In other words, how should i set the timestamp and sequence number if i
want to minimize the loss effect while not consume too much bandwith by
sending two packets with different clock rates? Or when switching to another
clock rate due to any reason?

    Any of your help is greatly appreciated, thx in advance!!

Sincerely,
zuobf
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Fri, 7 Jul 2006 13:01:04 +0100

On 7 Jul 2006, at 09:51, zuo bf wrote:
>       I am totally confused of how to set the timestamp if a stream  
> is negociated with some payload types of different clock rates,
> I didn't find anywhere mention this or even whether it's allowed.  
> But in reality, if allowed we may use different clock rates at  
> different
>      In other words, how should i set the timestamp and sequence  
> number if i want to minimize the loss effect while not consume too  
> much bandwith by sending two packets with different clock rates? Or  
> when switching to another clock rate due to any reason?

I would recommend to avoid using multiple clock rates within an RTP  
session where possible. RTP wasn't designed to support this, and  
there are a number of places where the semantics of the timestamp are  
less-than-clearly defined if the clock rate changes arbitrarily.

If you must use multiple clock rates, I would recommend that you use  
choose rates which are integer multiples of each other, change rates  
only on frame boundaries, avoid overlapping packets with different  
rates, and use several payload types to identify multiple-rate codecs  
(one payload type for each rate).

For example, assume the following SDP fragment:

       m=audio 12344 RTP/AVP 99 100
       a=rtpmap:99 G729/8000
       a=rtpmap:100 DVI/16000

Assume the application starts sending using G.729. The initial RTP  
sequence number and timestamp are randomly chosen. The sequence  
number increments by one of each packet sent. By default a G.729  
sender includes two 10ms frames per RTP packet (RFC 3551 Section  
4.5.6), so the timestamp increments by 160 per packet (8000 samples  
per second * 0.020 seconds).

Similar behaviour happens when sending using DVI with the default  
20ms packetization interval, except that the RTP timestamp increments  
by 320 per packet (16000 samples per second * 0.020 seconds).

When switching from G.729 to DVI, there is a clock rate change. That  
can be managed provided the change occurs at a packet boundary. For  
example:

    7 July 12:54:00.000    G729    ts  = 8000 seq = 1023
    7 July 12:54:00.020    G729    ts  = 8160 seq = 1024
    7 July 12:54:00.040    G729    ts  = 8320 seq = 1025
    7 July 12:54:00.060    G729    ts  = 8480 seq = 1026
    7 July 12:54:00.080    DVI     ts  = 8640 seq = 1027
    7 July 12:54:00.100    DVI     ts  = 8960 seq = 1028
    7 July 12:54:00.120    DVI     ts  = 9280 seq = 1029

Here, the clock rate changed at 12:54:00.080 when the first DVI  
packet was captured. The RTP timestamps before that time increment by  
160 per 20ms, after than time by 320 per 20ms.

The thread on "RFC2833 Question" a couple of weeks ago discusses this  
issue further, if you search the mailing list archives.

Colin