[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Jitter calculation with multiple rates [was Re: [Fwd: I-D Action:draft-petithuguenin-avt-multiple-clock-rates-00.txt]]
Responding to myself, see below.
Marc Petit-Huguenin wrote:
> 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
It seems that there is problems with what I said above. Nobody protested and it
seems to be in line with what Colin Perkins said, so there is a need for
clarification here.
But first of all let me state that I do not try to say that an RTP sender should
use multiple clock rates in the same SSRC as the current consensus is that
different SSRC should be used when the clock rate change. This discussion is
about what an RTP receiver should do when an RTP sender still use multiple clock
rates in the same SSRC, in the spirit of the "be liberal in what you accept"
part of the IETF motto.
The timestamp sequence above uses in fact the following formula for each packet:
timestamp = previous_timestamp + (current_capture_time - previous_capture_time)
* previous_clock_rate
The problem with this is that the jitter calculation on the receiving side does
not work during the transition between two clock rates:
Capture Clock RTP Arrival Transit Jitter Average
time rate ts time jitter
0 8000 0 0.1 800 N/A
0.02 8000 160 0.12 800 0 0
0.04 8000 320 0.14 800 0 0
0.06 8000 480 0.16 800 0 0
0.08 16000 800 0.18 2080 480 30
0.1 16000 1120 0.2 2080 0 28
0.12 16000 1440 0.22 2080 0 26
0.14 8000 1600 0.24 320 720 70
0.16 8000 1760 0.26 320 0 65
(The capture and arrival time are in seconds, starting at the beginning of the
capture of the first packet; clock rate is in Hz; the RTP timestamp [RTP ts]
does not include the random offset; the transit, jitter and average jitter use
the clock rate in the same line as unit)
Having the jitter work in this case means that the formula in RFC 3550 needs to
be modified.
An alternate way of generating the RTP timestamps is to use the following formula:
timestamp = capture_time * clock_rate
In this case, the jitter formula in RFC 3550 works without modification:
Capture Clock RTP Arrival Transit Jitter Average
time rate ts time jitter
0 8000 0 0.1 800 N/A
0.02 8000 160 0.12 800 0 0
0.04 8000 320 0.14 800 0 0
0.06 8000 480 0.16 800 0 0
0.08 16000 1280 0.18 1600 0 0
0.1 16000 1600 0.2 1600 0 0
0.12 16000 1920 0.22 1600 0 0
0.14 16000 2240 0.24 1600 0 0
0.16 16000 2560 0.26 1600 0 0
0.14 8000 1120 0.24 800 0 0
0.16 8000 1280 0.26 800 0 0
(The spreadsheet used to generate this tables is available[1])
It is true that with this formula the RTP timestamp no longer increments
monotonically but I think that this is still conform to RFC 3550, as it says
that "[t]he sampling instant MUST be derived from a clock that increments
monotonically[...]". It is the clock that increments monotonically, not the RTP
timestamp.
So my question to the WG is, which of the two methods above have been
implemented, and so which one (perhaps both, although I am not sure if it will
be possible to discover which one dynamically) should an RTP receiver use?
Thanks.
[1]
http://spreadsheets.google.com/ccc?key=0AndnqRvudSVbdHJhbVF4Sk5MRDEyaHhhc3M4TDRsaHc&hl=en
--
Marc Petit-Huguenin
Personal email: marc at petit-huguenin.org
Professional email: petithug at acm.org
Blog: http://blog.marc.petit-huguenin.org