Subject: [AVT] RTP Timestamp Frequency Change Handling

From: "O'Connor, Kevin" <[email-masked]>
Date: Wed, 16 Feb 2005 10:23:04 -0500

RFC 3550 states that the payload type of an RTP stream can change at any
time, and that the timestamp frequency is dependent on the payload type.
If the payload type changes mid-stream in a way that changes the
frequency of the timestamp (from 16kHz to 8kHz for example), how should
this be handled by the RTP receiver? Will the new timestamps continue
where the old left off (and now at the different frequency), or will
they be consistent with their wall-clock time association (meaning that
timestamp values could jump backward and forward at payload type
transitions)? Or, is a new random starting timestamp chosen?

Kevin O'Connor

Interactive Intelligence Inc.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Feb 2005 13:28:38 +0100

Hi Kevin,

O'Connor, Kevin wrote:
> RFC 3550 states that the payload type of an RTP stream can change at any time, and that the timestamp frequency is dependent on the payload type. If the payload type changes mid-stream in a way that changes the frequency of the timestamp (from 16kHz to 8kHz for example), how should this be handled by the RTP receiver? Will the new timestamps continue where the old left off (and now at the different frequency), or will they be consistent with their wall-clock time association (meaning that timestamp values could jump backward and forward at payload type transitions)? Or, is a new random starting timestamp chosen?
> 

The answer is that it needs to be continuous, having it jump is not an 
option. So an example of how it should behave:
Wall time: 0, TS: 0 TS freq:8kHz
Wall time 3.0 s TS: 24000 TS freq:8kHz
Lets change the TS frequency at exactly
Wall time: 6.0 TS: 48000 and From here TS frequency is 16kHz
Then the wall time 9.0 the TS value will be 96000.

One has simply to say that from a specific TS value the new frequency 
will be used. And that point should correspond to the first media packet 
at the new frequency.

There are a few words of caution that should be provided here. If that 
first media packet is lost, the synchronization is not established until 
the next RTCP packet is received, because the receiver will not know 
without RTCP exactly when the change actually happened. Frequent 
switching would create great problems as there is need for RTCP to 
maintain synchronization in the case of packet losses.

Although allowed by the specification, I expect many implementations to 
have problems with a RTP payload switching that result in a change of 
used timestamp frequency.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]