Subject: [AVT] RTP timestamp adjustment?

From: "Wong, David" <[email-masked]>
Date: Wed, 10 Jul 2002 12:07:25 -0400

I have a question about the value for the timestamp that should go into the
RTP header for audio (say G.711). Say that the system that is generating RTP
is under heavy load, and as a result the processing (ie the sampling of the
audio and the generation of the RTP packets) is shifted from time to time
(say, by .125 ms). Should the RTP timestamp be updated appropriately (for
example, updated by 1 timestamp unit--if the original value was 160, then
updated to 161) or should the value that goes into the header be the
timestamp value that the audio should have been sampled at (160)?

David Wong
Software Engineer
Communications Infrastructure Test Group

p| 978.661.1241 f| 978.988.0148
email | [email-masked]
205 Lowell Street | Wilmington, MA | 01887

E M P I R I X
http://www.empirix.com <http://www.empirix.com/>

---

From: "Alan Clark" <[email-masked]>
Date: Wed, 10 Jul 2002 12:26:26 -0400

David

According to my interpretation of RTP you could do either, as this would
correspond to your sampling clock being updated irregularly .. not a good
idea but it could happen.

Slow drift in sampling clock speed can occur in practice however this would
normally result in an occasional frame being dropped or inserted rather than
shifts of one sample interval in the RTP timestamp.  If you want to make the
inability of the test system to keep up look like clock drift then you could
keep the timestamp numbering consecutive.  If you have occasional jumps in
the RTP timestamp it is hard to predict what may happen - many jitter
buffers don't rely too much on the timestamp however some may.

Regards

Alan Clark
Telchemy

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Wong,
David
  Sent: Wednesday, July 10, 2002 12:07 PM
  To: [email-masked]
  Subject: [AVT] RTP timestamp adjustment?

  I have a question about the value for the timestamp that should go into
the RTP header for audio (say G.711). Say that the system that is generating
RTP is under heavy load, and as a result the processing (ie the sampling of
the audio and the generation of the RTP packets) is shifted from time to
time (say, by .125 ms). Should the RTP timestamp be updated appropriately
(for example, updated by 1 timestamp unit--if the original value was 160,
then updated to 161) or should the value that goes into the header be the
timestamp value that the audio should have been sampled at (160)?
  David Wong
  Software Engineer
  Communications Infrastructure Test Group

  E M P I R I X
  http://www.empirix.com

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Jul 2002 10:15:14 +0200

Hi David,

My strong recommendations would be to keep the regular timestamp 
increase. If the clock in reality is running at somewhat slower 
frequency than 8000 this should then be signaled in RTCP by giving 
accurate NTP to timestamp bindings. If you don't signal this the effect 
will be that the receiver tries to play it with less and less delay 
between sender side sampling and receiver side playback. This will most 
probable eat up the receivers jitterbuffer which should try to adapt to it.

If you would do 161 instead of 160 increase in the timestamp between 
packets the receiver should place the samples 161 samples from the 
previous packets first sample. This will of course result in a one 
sample whole in the playout buffer for each packet. This may have all 
sorts of bad effects, from software that can't handle this very 
untypical timestamp increase to lack of error concealment of the missing 
sample creating annoying audio effects.

In the case of AMR and most probable other frame based codecs this does 
not work at all. When decoding the data stream it must be done frame by 
frame and you can't skip or add a few samples in a frame. It is of 
course possible to add a few samples after decoding is done. It is 
however much better to adjust for the clock skew by periodically insert 
either a whole frame (preferable a no_data frame during DTX) before 
decoding or add extra samples with concealment.  The payload 
depacketization may also derail due to having non-standard timestamp 
increase, especially when interleaving is used.

My point is: Use regular timestamp increase and use the RTCP mechanism 
to report the clock skew.

Regards

Magnus

Wong, David wrote:

> I have a question about the value for the timestamp that should go 
> into the RTP header for audio (say G.711). Say that the system that is 
> generating RTP is under heavy load, and as a result the processing (ie 
> the sampling of the audio and the generation of the RTP packets) is 
> shifted from time to time (say, by .125 ms). Should the RTP timestamp 
> be updated appropriately (for example, updated by 1 timestamp unit--if 
> the original value was 160, then updated to 161) or should the value 
> that goes into the header be the timestamp value that the audio should 
> have been sampled at (160)?
>
> David Wong
> Software Engineer
> 205 Lowell Street| Wilmington, MA| 01887
>
> E M P I R I X

-- 

Magnus Westerlund 

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

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