Subject: [AVT] Clock rate used for RTP timestamps

From: "Shailendra Singh" <[email-masked]>
Date: Tue, 8 May 2007 16:16:32 +0530

Hi All,
    For H.264 and H.263, the corresponding RFCs mandate that a clock rate
(for RTP timestamping) of 90 kHz MUST be used.
    For MPEG-4, RFC 3016 (RTP Payload Format for MPEG-4 Audio/Visual
Streams) says that the resolution of the RTP timestamp "is set to its
default value of 90kHz, unless specified by an out-of-band means", i.e. a
clock rate which is not 90 kHz is allowed if explicitly specified, for
example, in a Session Description sent out with the "rate" parameter in the
"a=rtpmap" line appropriately set.

My questions are:
(1) What is the need to allow a non 90 kHz clock rate for MPEG-4 when the
other coding systems restrict it to 90 kHz?
(2) RFC 3016 does not say anything explicitly, but is there an implied
restriction on the range in which the clock rate should lie for MPEG-4?

Any pointers will be appreciated.

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

---

From: Dave Singer <[email-masked]>
Date: Tue, 8 May 2007 09:19:56 -0700

At 16:16  +0530 8/05/07, Shailendra Singh wrote:
>Hi All,
>     For H.264 and H.263, the corresponding RFCs mandate that a clock 
>rate (for RTP timestamping) of 90 kHz MUST be used.
>Streams) says that the resolution of the RTP timestamp "is set to 
>its default value of 90kHz, unless specified by an out-of-band 
>means", i.e. a clock rate which is not 90 kHz is allowed if 
>explicitly specified, for example, in a Session Description sent out 
>with the "rate" parameter in the "a=rtpmap" line appropriately set.
>
>My questions are:
>(1) What is the need to allow a non 90 kHz clock rate for MPEG-4 
>when the other coding systems restrict it to 90 kHz?
>(2) RFC 3016 does not say anything explicitly, but is there an 
>implied restriction on the range in which the clock rate should lie 
>for MPEG-4?

Generally my feeling is that the systems which insist on 90 kHz are 
over-specified.  For example, if my frame rate is actually 15 
frames/second, then a clock of 3000 is probably enough to measure 
frame times, jitter, etc.

Indeed, 30000 is enough for exact NTSC with frame dropping (each 
frame has a 'duration' of 1001).  Overall, my preference is to see 
drafts that give guidance on how to choose the clock rate, but leave 
the final decision to the content creator.

(But I have seen streams which have too low a rate for all the ways 
the clock is used, I confess).
-- 
David Singer
Apple Computer/QuickTime

---

From: "Jaehwan Kim" <[email-masked]>
Date: Wed, 9 May 2007 10:40:12 +0900

Hi,
>From my understanding, 90k is the most generic rate to cover most of all
framerates(usually common multiple). In fact, the best way is to use
framerate itself because converting timestamp to 90khz rate might change
the precision of it. 

So, there are some streams using rate value 1 or 5. If jitter
calculation is really important, however, it is known that you should
avoid extremely low rate value because RTCP jitter calculation is not
exact in that case(you can infer from RFC3550 page40). In the mean time,
if you are using too big one like 900khz, it will cause very quick
wrap-around. Basically, it should be ok, but it is good to avoid 'too
much and too fast wrap-around' for immature but commercial applications.

Therefore, I tell my colleague to use big enough value as Dave Singer
suggested. And that value should be a multiple of framerate.

Cheers,
Jaehwan
In some cases, we had to fix it as 1000(it is millisecond!) in a project
because some people believe easy interpretation is the best. :->