Re: [AVT] [Fwd: I-D Action:draft-petithuguenin-avt-multiple-clock-rates-00.txt]

[Marc Petit-Huguenin <petithug at acm.org>]

Hi Jossen,

Jochen Issing wrote:
> Hi Marc,
> 
> sorry for not having responded to your I-D. I read it and found it a
> good basis for further discussion. Anyhow, I could agree with the
> approach of letting the payload specifications decide, how timestamps
> and timescales are interpreted. Anyhow, the timestamps might no longer
> be monotonically increasing and thus breaking RFC3550?

The way I understand how it would work for multiple rates in the same SSRC is
that the timestamp would always increase.  Let's say that there is two payload
types, 96 for a clock rate of 8000 and 97 for a clock rate of 16000.  With
packets each 20 milliseconds long, a packet with pt=96 would increase the
timestamp by 160 and a packet with pt=97 would increase it by 320.  So we would
have the following sequence (without the timestamp random offset):

PT  timestamp
96          0
96        160
97        320
97        640
96        960
96       1120

> 
> In our implementation, we do not support different timescales with the
> same payload type. For our adaptative RTP streaming, we are using a
> self-derived non-public payload format.

Thanks.

-- 
Marc Petit-Huguenin
Personal email: marc at petit-huguenin.org
Professional email: petithug at acm.org
Blog: http://blog.marc.petit-huguenin.org