Re: [AVT] Q for 3984bis-06

[stephen botzko <stephen.botzko at gmail.com>]

This makes sense to me.  

Of course it does not apply to profiles, since the profiles are not intended to form a hierarchy.  But the levels do form a hierarchy - the ability to decode level 3.1 of a given profile implies the ability to decode all lower levels.

Regards,
Stephen Botzko

On Mon, May 18, 2009 at 11:57 AM, Ye-Kui Wang <yekuiwang at huawei.com> wrote:

Tom, All,

Let me try to give a summary of the discussion of level upgrade. To my
understanding, there has been no clear conclusion that level upgrade is
absolutely needed, and there has been no clear proposal that has no issue.
For support of the original use case Ashish Goyal proposed, which is copied
below for convenience, there is no need to change anything in the draft

"Here is how the use case is expected to work.
 Assume the video device A is able to decode level 3.1 and encode only
level 1.1
 B is capable of both decoding and encoding level 3.1.
 A would quote a level of 3.1 in its offer
 B would respond with level 3.1 in the answer
 A would send to B video stream at level 1.1 - since A can only encode at
level 1.1.
 B would send level 3.1 to A since A can decode upto level 3.1."

Therefore, my take is not to make any change in this regard. Any different
opinions?

BR,YK

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On

> Behalf Of Ye-Kui Wang
> Sent: Tuesday, May 12, 2009 9:50 AM
> To: 'Tom Taylor'
> Cc: ron.even.tlv at gmail.com; avt at ietf.org
> Subject: Re: [AVT] Q for 3984bis-06
>
>
> Yes, please go ahead.
>
> BR,YK
>
> > -----Original Message-----
> > From: Tom Taylor [mailto:tom.taylor at rogers.com]
> > Sent: Tuesday, May 12, 2009 3:58 AM
> > To: Ye-Kui Wang
> > Cc: 'Ali C. Begen (abegen)'; avt at ietf.org; ron.even.tlv at gmail.com
> > Subject: Re: [AVT] Q for 3984bis-06
> >
> > I was waiting for the discussion of level upgrade to settle.
> > Should I issue a summary of what I have seen so far?
> >
> > Ye-Kui Wang wrote:
> > > 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
> > >>
> > >
> > >
> > >
> >
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt