Thanks Ali. This is an intact inheritance from RFC 3984. I'd agree to remove
the note in the next submission.
BTW, AVT Chairs, what is the plan on progressing this and the SVC drafts?
BR, YK
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
Behalf Of Ali C. Begen (abegen)
Sent: Monday, May 11, 2009 5:08 PM
To: avt at ietf.org
Subject: [AVT] Q for 3984bis-06
Page 12 says:
Informative note: Because H.264 allows the decoding order to
be different from the display order, values of RTP
timestamps
may not be monotonically non-decreasing as a function of RTP
sequence numbers. Furthermore, the value for inter-arrival
This is not something specific for H.264 content. It applies
to almost all codecs. A rewording may be beneficial IMO.
jitter reported in the RTCP reports may not be a trustworthy
indication of the network performance, as the calculation
rules for inter-arrival jitter (section 6.4.1 of RFC 3550)
assume that the RTP timestamp of a packet is directly
proportional to its transmission time.
What does it mean that RTP timestamp is proportional to its
transmission time? By "transmission time" do you mean the
instant the packet was sent? By definition, timestamp
reflects the sampling instant of the first octet in the RTP
packet. The packets belong to a single video frame will most
likely have the same timestamp. But that does not mean that
they will be transmitted at the same time.
RFC 3550 has a simple rule here and says this rule must be
followed. The packets are considered in the order they
arrive, not based on their seqnums in the jitter calculation.
And the parameters needed to compute the interarrival jitter
are clock rate, timestamp and arrival-time timestamp.
I suggest a revision for this informative note, or we can
simply remove it since section 6.4.4 of RFC 3550 already
provides a more-than-sufficient explanation.
-acbegen
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt