Re: [AVT] Q for 3984bis-06

[Ye-Kui Wang <yekuiwang at huawei.com>]

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
>