[Mp4-tech] Clock rate used for RTP timestamps

[Jalan, Manish]

Hi Shailendra,
No direct answers. Some personal thoughts.
For first part of your query: Why to allow non 90 KHz clock?
AFAIK, H.264 and H.263 are video only standards. Hence if their
corresponding RTP payload format RFCs mandate a 90 KHz clock rate, makes
sense.
Coming to MPEG-4, it's not a video-only standard. If I know it right, it
can be audio only, video only or audio video both. 90 KHz clock is
justified / suggested for video. When audio is present, a different
clock might be suitable that will ensure audio / video sync.
For answering second part of your query, following might be useful.
Quoting from RFC 1890,
"...All current video encodings use a timestamp frequency of 90,000 Hz,
the same as the MPEG presentation time stamp frequency. This frequency
yields exact integer timestamp increments for the typical 24 (HDTV), 25
(PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates and 50, 59.94 and
60 Hz field rates. While 90 kHz is the recommended rate for future video
encodings used within this profile, other rates are possible. However,
it is not sufficient to use the video frame rate (typically between 15
and 30 Hz) because that does not provide adequate resolution for typical
synchronization requirements when calculating the RTP timestamp
corresponding to the NTP timestamp in an RTCP SR packet [15]. The
timestamp resolution must also be sufficient for the jitter estimate
contained in the receiver reports."
Quoting from RFC 1889,
"RTP timestamp: 32 bits
        Corresponds to the same time as the NTP timestamp (above), but
in the same units and with the same random offset as the RTP timestamps
in data packets. This correspondence may be used for intra- and
inter-media synchronization for sources whose NTP timestamps are
synchronized, and may be used by media-independent receivers to estimate
the nominal RTP clock frequency. Note that in most cases this timestamp
will not be equal to the RTP timestamp in any adjacent data packet.
Rather, it is calculated from the corresponding NTP timestamp using the
relationship between the RTP timestamp counter and real time as
maintained by periodically checking the wallclock time at a sampling
instant."
Quotes from 'http://www.cs.columbia.edu/~hgs/rtp/faq.html'
"In a multimedia conference, are the initial timestamp values related?
    No, initial time stamp values are picked randomly and independently
for each RTP stream. (This is more or less unavoidable if different
media types are generated by independent applications, whether these
applications reside on the same host or not.) Synchronization (such as
lip sync) between different media is performed by receivers through the
NTP timestamps in the RTCP sender reports. This timestamp provides a
common time reference that associates a media-specific RTP timestamp
with the common "wallclock" time shared across media. The mechanism how
end systems synchronize different media is not prescribed by RTP,
however, a workable approach is to periodically exchange messages
between applications to indicate what delay each application would
impose on the stream (including any media decoding delays) if it were
not to synchronize and then have all applications choose the maximum of
these delays.
What are the roles of the RTP timestamp and sequence numbers?
    The timestamp is used to place the incoming audio and video packets
in the correct timing order (playout delay compensation). The sequence
number is mainly used to detect losses. Sequence numbers increase by one
for each RTP packet transmitted, timestamps increase by the time
"covered" by a packet. For video formats where a video frame is split
across several RTP packets, several packets may have the same timestamp.
In some cases such as carrying DTMF (touch tone) data (RFC 2833), RTP
timestamps may not be monotonic.
What are the different clocks and how are they synchronized?
    RFC 1889 specifies one media-timestamp in the RTP data header and a
mapping between such timestamp and a globally synchronized clock,
carried as RTCP timestamp mappings. The NTP timestamps in the SR are
assumed to be synchronized between all media senders within a single
session. If the media sources come from the same network source, this is
obviously not an issue. Receiver(s) synchronize to the sender, the only
solution feasible for multicast. Experience has shown that all other
cross-media, cross-host schemes end up doing clock synchronization,
usually inferior to NTP and application-specific."
Hope this helps.
Regards,
-Manish S. Jalan
________________________________
From: mp4-tech-bounces lists.mpegif.org
[mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Shailendra Singh
Sent: Tuesday, May 08, 2024 4:15 PM
To: mp4-tech lists.mpegif.org
Subject: [Mp4-tech] Clock rate used for RTP timestamps
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 
http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_____________________________________________________________________
This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete  this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at netadmin patni.com and delete this mail. 
_____________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20070509/960ae338/attachment-0001.html