[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] RTP Timestamp Frequency Change Handling
Thank you for the clarification. I assume that if there is suppressed
silence prior to the payload type change, the missing timestamps
representing that silence are assumed to be at the previous payload
type's frequency. Is that correct?
-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com]
Sent: Thursday, February 17, 2005 7:29 AM
To: O'Connor, Kevin
Cc: avt at ietf.org
Subject: Re: [AVT] RTP Timestamp Frequency Change Handling
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: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt