[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
Roni,
> Does this mean that you are considering adding level upgrade
> but just arguing the text?
Yes, unless it is finally concluded that there is no need or there is a big
problem that does not worth the addition.
BR, YK
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Wednesday, May 20, 2009 2:56 PM
> To: 'Ye-Kui Wang'; 'Randell Jesup'
> Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; avt at ietf.org;
> 'stephen botzko'
> Subject: RE: [AVT] Q for 3984bis-06
>
> YK,
> Does this mean that you are considering adding level upgrade
> but just arguing the text?
>
> Anyhow Tom will need to call for a consensus on the change
> based on the long discussion starting with the email from
> Ashish (May 4th)
>
> Roni
>
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> Behalf Of Ye-Kui Wang
> Sent: Wednesday, May 20, 2009 9:11 PM
> To: 'Roni Even'; 'Randell Jesup'
> Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; avt at ietf.org;
> 'stephen botzko'
> Subject: Re: [AVT] Q for 3984bis-06
>
>
> Roni,
>
> Right, we are discussing possible approaches to acheive level
> upgrade. The hottest one has been what Randell proposed
> (level-upgrade-allowed), but it seems that there is something
> disconnecting Randell and myself, and we are working hard to
> find that out :-) I believe all the discussions are good to
> help us making a fully informed decision.
>
> BR, YK
>
> > -----Original Message-----
> > From: Roni Even [mailto:Even.roni at huawei.com]
> > Sent: Wednesday, May 20, 2009 2:00 PM
> > To: 'Ye-Kui Wang'; 'Randell Jesup'
> > Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; 'stephen botzko';
> > avt at ietf.org
> > Subject: RE: [AVT] Q for 3984bis-06
> >
> > YK,
> >
> > The semantics of the parameters now is correct, what I was
> saying is
> > that there may be a difference between what a device is
> offering and
> > what the device can do in terms of processing, this can
> happen due to
> > other decisions like configuration and it may go higher if
> the other
> > side indicates that it can do so.
> >
> > I think allowing level upgrade by the answerer is what all
> the people
> > discussing the topic draft are suggesting (Ingemar,
> Randell, Jonathan,
> > Magnus and others). I just gave another example where it can happen.
> > Maybe clarify that the level is a receive capability will help.
> >
> > Jonathan Lennox even suggests " Architecturally, I think it
> would be
> > cleanest if H.264's non sprop-* parameters all have SDP's standard
> > receive-side semantics, rather than offer/answer semantics."
> >
> > Roni Even
> > -----Original Message-----
> > From: Ye-Kui Wang [mailto:yekuiwang at huawei.com]
> > Sent: Wednesday, May 20, 2009 8:25 PM
> > To: 'Roni Even'; 'Randell Jesup'
> > Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; 'stephen botzko';
> > avt at ietf.org
> > Subject: RE: [AVT] Q for 3984bis-06
> >
> >
> > Roni,
> >
> > > -----Original Message-----
> > > From: Roni Even [mailto:Even.roni at huawei.com]
> > > Sent: Wednesday, May 20, 2009 12:41 PM
> > > To: 'Ye-Kui Wang'; 'Randell Jesup'
> > > Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; 'stephen botzko';
> > > avt at ietf.org
> > > Subject: RE: [AVT] Q for 3984bis-06
> > >
> > > YK,
> > > An offer of level 1.3 is just an offer, it is not
> necessarily what
> > > the device can do. The reasons for offering a lower level can be
> > > due to multiple reasons, like some configuration of the
> terminal and
> > > not based on encoder/decoder performance.
> > >
> >
> > If this is the case, then the current semantics of
> profile-level-id is
> > simply incorrect as it reads.
> >
> > > Having said that I would like to point out that in most cases you
> > > can get higher functionality by using other parameters
> like offering
> > > level 3.1 and using max-fs, max-br and max-cpb parameter to offer
> > > support for HD picture (using max-fs and
> > > max-cpb) at higher bit rate (based on max-br) which are
> over level
> > > 3.1 according to table A-1 in H.264. This is very typical
> in video
> > > conferencing applications if the offerer cannot support the maxBR
> > > for level 4 in table A-1.
> >
> > Correct.
> >
> > > I think that in this case it is reasonable for the answer
> to signal
> > > level 4 since it gives similar resolution but hinting that it can
> > > encode and decode higher bit rate. This will not break
> > > interoperability and make it simpler for the answerer.
> >
> > I don't think this is correct according to either RFC 3984
> or the bis.
> > As you said earlier, it is allowed to signal level 3.1, and to use
> > those max-* parameters to indicate that the device has
> higher than 3.1
> > capability in a particular aspect, but not the other way
> round. If you
> > signal level 4, there is no way to tell which aspect of the
> capability
> > is lower than level 4. This is simply not what the spec
> says. If you
> > think this way should be supported, you must propose it and make it
> > said in the spec.
> >
> > BR, YK
> >
> > >
> > > Roni
> > >
> > > -----Original Message-----
> > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]
> On Behalf
> > > Of Ye-Kui Wang
> > > Sent: Wednesday, May 20, 2009 7:07 PM
> > > To: 'Randell Jesup'
> > > Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; 'stephen botzko';
> > > avt at ietf.org
> > > Subject: Re: [AVT] Q for 3984bis-06
> > >
> > >
> > > Typo: encoded -> decode. So, the sentence should be as follows.
> > >
> > > " The whole point is, if the offer contians level 1.3 (per
> > > 3984 or the bis
> > > draft) with sendrecv or no direction attribute, then level
> > > 1.3 is the highest it can both encoded and encode. In
> this case, it
> > > simply cannot encode above level 1.3. "
> > >
> > > BTW, it is not absolutely prohibited to change the semantics of
> > > profile-level-id, I am just saying that you need to change the
> > > semantics. In addition, if the encoding/sending
> capability and the
> > > decoding/receiving capability is different, both
> capabiilties should
> > > be expressed. One way is to use different direction
> attributes (and
> > > separate SDP), which was considered not perfect. The
> other way is,
> > > as I mentioned earlier, to use two parameters, one for each.
> > >
> > > BR, YK
> > >
> > > > -----Original Message-----
> > > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > > Behalf Of
> > > > Ye-Kui Wang
> > > > Sent: Wednesday, May 20, 2009 11:52 AM
> > > > To: 'Randell Jesup'
> > > > Cc: ron.even.tlv at gmail.com; 'stephen botzko';
> avt at ietf.org; 'Tom
> > > > Taylor'
> > > > Subject: Re: [AVT] Q for 3984bis-06
> > > >
> > > >
> > > > > For example, if the offer is 1.3 with
> > > > level-upgrade-allowed=1, and the
> > > > > answer is level 3.1, then the offerer can send at any level
> > > > up to and
> > > > > including level 3.1. It could send level 2.0 if that's the
> > > > highest it
> > > > > can encode.
> > > >
> > > > The whole point is, if the offer contians level 1.3 (per
> > > 3984 or the
> > > > bis
> > > > draft) with sendrecv or no direction attribute, then level
> > > > 1.3 is the highest it can both encoded and encode. In
> > this case, it
> > > > simply cannot encode above level 1.3.
> > > >
> > > > Text in 3984:
> > > > If the profile-level-id parameter
> > > is used for
> > > > capability exchange or session setup
> > > > procedure,
> > > > it indicates the profile that the codec
> > > > supports and the highest level
> > > > supported for the signaled profile.
> > > >
> > > > BR, YK
> > > >
> > > > > -----Original Message-----
> > > > > From: Randell Jesup [mailto:rjesup at wgate.com]
> > > > > Sent: Wednesday, May 20, 2009 1:08 AM
> > > > > To: Ye-Kui Wang
> > > > > Cc: 'stephen botzko'; ron.even.tlv at gmail.com; 'Tom Taylor';
> > > > > avt at ietf.org
> > > > > Subject: Re: [AVT] Q for 3984bis-06
> > > > >
> > > > > Ye-Kui Wang <yekuiwang at huawei.com> writes:
> > > > > >> So, to summarize, if in response to an offer with
> > > > > >> level-upgrade-allowed=1, the answer includes a level
> > > > > higher than the
> > > > > >> offerer supports:
> > > > > >>
> > > > > >> * The offerer can encode a stream as if it's a higher
> > > > > level (including
> > > > > >> parameter sets), but using the encode settings of a
> > > > > lower level that
> > > > > >> it supports.
> > > > > >
> > > > > >So, in your interpretation, the offerer sending a higher
> > > > level just
> > > > > >means that it sends sequence parameter sets containing
> > > the higher
> > > > > >level, but the bitstream characteristics are still
> > > > restricted by the
> > > > > >lower level. How could this bring any practical
> > > usefulness? In the
> > > > > >example, offer includes level B (e.g. spatial resolution up
> > > > > to QVGA),
> > > > > >and the answer includes a higher level C (e.g. spatial
> > > > > resolution up to
> > > > > >VGA), then both sides still send and receive up to QVGA
> > > > > resolution, but
> > > > > >the offer includes sequence parameter sets include the level
> > > > > value C. Why is this useful at all?
> > > > >
> > > > > You asked a different question:
> > > > >
> > > > > >> >Now with the correct reading of the table. Again, that
> > > > > just makes a
> > > > > >> >difference on receiving or sending capability, not the
> > > > > conclusion.
> > > > > >> >You are basically assuming that the offerer's
> sending (i.e.
> > > > > >> >encoding) capability is not limited, i.e. it can send
> > > > > whatever high
> > > > > >> >level the answer may include. How can that assumption
> > > > be correct?
> > > > >
> > > > > You asked about sending at "whatever high level the
> answer may
> > > > > include".
> > > > > My response shows that you don't have to send at an
> > > > arbitrarily-high
> > > > > level
> > > > > - you can send at the highest level you support.
> > > > >
> > > > > For example, if the offer is 1.3 with
> > > > level-upgrade-allowed=1, and the
> > > > > answer is level 3.1, then the offerer can send at any level
> > > > up to and
> > > > > including level 3.1. It could send level 2.0 if that's the
> > > > highest it
> > > > > can encode.
> > > > >
> > > > > >BR, YK
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Randell Jesup [mailto:rjesup at wgate.com]
> > > > > >> Sent: Wednesday, May 20, 2009 12:29 AM
> > > > > >> To: Ye-Kui Wang
> > > > > >> Cc: 'stephen botzko'; ron.even.tlv at gmail.com; 'Tom
> Taylor';
> > > > > >> avt at ietf.org
> > > > > >> Subject: Re: [AVT] Q for 3984bis-06
> > > > > >>
> > > > > >> Ye-Kui Wang <yekuiwang at huawei.com> writes:
> > > > > >>
> > > > > >> >I shortened the text.
> > > > > >> >
> > > > > >> >> If the offerer is legacy, then they don't include
> > > > > >> >> level-upgrade-allowed, and as stated the answerer is not
> > > > > >> allowed to
> > > > > >> >> upgrade the level. If the answerer is legacy, then they
> > > > > >> will ignore
> > > > > >> >> level-upgrade-allowed, and won't upgrade the level. So
> > > > > >> those 3 cases are all handled.
> > > > > >> >
> > > > > >> >OK. But it is possible that the answerer is new but does
> > > > > not want to
> > > > > >> >upgrade the level in an offer/answer process. It would be
> > > > > certainly
> > > > > >> >useful that the answerer lets the other side know
> whether it
> > > > > >> is new or
> > > > > >> >legacy. Therefore, I'd prefer to include
> > > > > >> level-upgrade-allowed equal to
> > > > > >> >1 if the device is new (does understand the parameter and
> > > > > >> allows level
> > > > > >> >upgrade). Note that something is allowed does not mean it
> > > > > is in use.
> > > > > >>
> > > > > >> The answerer could do that, and I don't have a problem
> > > > with it (it
> > > > > >> doesn't hurt anything), but I don't see how it's useful
> > > > in any way.
> > > > > >>
> > > > > >> >> >The conflict is at the offerer's side. It includes a
> > > > > lower level,
> > > > > >> >> >but you are proposing requires that the offerer can
> > > > > >> receive a higher
> > > > > >> >> >level. To do this, you must change the current
> > > semantics of
> > > > > >> >> >profile-level-id.
> > > > > >> >>
> > > > > >> >> No, unless we decide to take the option mentioned in my
> > > > > >> table (change
> > > > > >> >> it to "level-asymmetry-allowed"). Then (and only then)
> > > > > could the
> > > > > >> >> offerer could receive a level above what they offered.
> > > > > >> >
> > > > > >> >Sorry, I mis-read your table. But that just makes a
> > > > difference on
> > > > > >> >receiving or sending capability, not the
> conclusion. In the
> > > > > >> righ case
> > > > > >> >in the table (i.e. offer includes B, and answer
> > > > includes C). The
> > > > > >> >current semantics say that the offerer would only
> be able to
> > > > > >> send B and
> > > > > >> >lower. But you want the offerer to be able to send C which
> > > > > >> is higher than B.
> > > > > >>
> > > > > >> I don't understand what you're trying to say here. That's
> > > > > the point
> > > > > >> of level upgrade. And the offerer is still sending
> > at a level
> > > > > >> specified in the answers profile-level-id.
> > > > > >> Perhaps you're just saying "yes, this means the offerer
> > > > > might end up
> > > > > >> sending a stream at a higher level than it offered",
> > > > which is the
> > > > > >> whole point of level upgrade.
> > > > > >>
> > > > > >> >> >> Perhaps this table will help:
> > > > > >> >> >>
> > > > > >> >> >> Offer is level "B". I'll use level "A" to indicate a
> > > > > >> lower level,
> > > > > >> >> >> and "C" for a higher one (A < B < C). I'm assuming
> > > > > the offer
> > > > > >> >> >> includes level-upgrade-allowed=1.
> > > > > >> >> >>
> > > > > >> >> >>
> > > > > >> >> >> Answer level: lower (A) same (B)
> > > > higher (C)
> > > > > >> >> >>
> > > > > >> >> >> Offerer can send: A B
> C
> > > > > >> >> >> Answerer can send: A* B
> B
> > > > > >> >> >>
> > > > > >> >> >
> > > > > >> >> >In the right case (the answer includes level C),
> > > what if the
> > > > > >> >> >offerer's receiveing capability is actually
> lower than C?
> > > > > >> >>
> > > > > >> >> Then they shouldn't answer with "C". They should
> > > answer with
> > > > > >> >> whatever level they do support. The point of this is
> > > > > to allow the
> > > > > >> >> answerer to offer to receive a higher level; they get to
> > > > > >> choose what
> > > > > >> >> that level is.
> > > > > >> >
> > > > > >> >Now with the correct reading of the table. Again, that
> > > > > just makes a
> > > > > >> >difference on receiving or sending capability, not the
> > > > > >> conclusion. You
> > > > > >> >are basically assuming that the offerer's sending (i.e.
> > > > encoding)
> > > > > >> >capability is not limited, i.e. it can send whatever high
> > > > > >> level the answer may include.
> > > > > >> >How can that assumption be correct?
> > > > > >>
> > > > > >> You need to think about how level works in H.264.
> > > > > >>
> > > > > >> Remember we're only changing level, not constraints or
> > > profiles.
> > > > > >>
> > > > > >> Levels imply details about the maximum frame size, maximum
> > > > > >> macroblocks per second, maximum bitrate, etc, and each
> > > > level is a
> > > > > >> superset of the next-lower level. Using a level doesn't
> > > > > mean you (as
> > > > > >> an encoder) have to hit those maximums. If you encode a
> > > > > stream using
> > > > > >> the parameters of a lower level (i.e.
> > > > > >> using lower maximums), it's decodable by a higher-level
> > > > > decoder, even
> > > > > >> if you set the parameter sets to the higher level.
> > > > > >>
> > > > > >> Even more importantly, there's no apparent
> > requirement to send
> > > > > >> exactly the level given by the profile-level-id; sending
> > > > > lower levels
> > > > > >> (with the correct profile and constraints) appears to be
> > > > just fine
> > > > > >> (note that this interacts with parameter-set handling -
> > > > > you need to
> > > > > >> deal with making sure the decoder has correct parameter
> > > > > sets, as you
> > > > > >> always do).
> > > > > >>
> > > > > >> From 3984:
> > > > > >>
> > > > > >> If the profile-level-id parameter is used to indicate
> > > > > properties
> > > > > >> of a
> > > > > >> NAL unit stream, it indicates the profile and level
> > > > > that a decoder
> > > > > >> has
> > > > > >> to support in order to comply with [1] when it decodes
> > > > > the stream.
> > > > > >>
> > > > > >> and
> > > > > >>
> > > > > >> If the profile-level-id parameter is used for
> > > > > capability exchange
> > > > > >> or
> > > > > >> session setup procedure, it indicates the profile
> > > > that the codec
> > > > > >> supports and the highest level supported for the
> > > > > signaled profile.
> > > > > >>
> > > > > >> Note "highest level". And:
> > > > > >>
> > > > > >> The level conveyed in the value of the profile-level-id
> > > > > parameter
> > > > > >> MUST
> > > > > >> be such that the receiver is fully capable of
> supporting.
> > > > > >>
> > > > > >> and
> > > > > >> o Parameters used for declaring receiver
> > > capabilities are in
> > > > > >> general
> > > > > >> downgradable; i.e., they express the upper limit for
> > > > > a sender's
> > > > > >> possible behavior. Thus a sender MAY select to set
> > > > > its encoder
> > > > > >> using only lower/lesser or equal values of these
> > > > parameters.
> > > > > >> [snip]
> > > > > >> o Parameters declaring a configuration point are not
> > > > > downgradable,
> > > > > >> with the exception of the level part of the
> > > > > "profile-level-id"
> > > > > >> parameter. This expresses values a receiver expects
> > > > > to be used
> > > > > >> and must be used verbatim on the sender side.
> > > > > >>
> > > > > >>
> > > > > >> So, to summarize, if in response to an offer with
> > > > > >> level-upgrade-allowed=1, the answer includes a level
> > > > > higher than the
> > > > > >> offerer supports:
> > > > > >>
> > > > > >> * The offerer can encode a stream as if it's a higher
> > > > > level (including
> > > > > >> parameter sets), but using the encode settings of a
> > > > lower level
> > > > > >> that it
> > > > > >> supports.
> > > > > >> * The offerer can encode a stream using a lower level,
> > > including
> > > > > >> lower-level parameter sets.
> > > > > >>
> > > > > >> In both cases, the parameter sets must be conveyed to the
> > > > > answerer in
> > > > > >> some manner; the mechanisms that would make the most
> > sense are
> > > > > >> in-band parameter sets (with all that implies), or using
> > > > > >> sprop-level-parameter-sets including levels above the
> > > > level in the
> > > > > >> offered profile-level-id, so that the answer can select
> > > > > one of those
> > > > > >> levels and thus install those parameter sets.
> > > > > >>
> > > > > >> None of this requires any further modification to 3984bis
> > > > > that I can
> > > > > >> see - just allowing level-upgrade-allowed (or
> > > > > >> level-asymmetric-allowed).
> > > > > >>
> > > > > >> --
> > > > > >> Randell Jesup, Worldgate (developers of the Ojo
> > > > > videophone), ex-Amiga
> > > > > >> OS team rjesup at wgate.com "The fetters imposed on liberty
> > > > > at home have
> > > > > >> ever been forged out of the weapons provided for
> > > defence against
> > > > > >> real, pretended, or imaginary dangers from abroad."
> > > > > >> - James Madison, 4th US president (1751-1836)
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Randell Jesup, Worldgate (developers of the Ojo
> > > > videophone), ex-Amiga
> > > > > OS team rjesup at wgate.com "The fetters imposed on liberty at
> > > > home have
> > > > > ever been forged out of the weapons provided for defence
> > > > against real,
> > > > > pretended, or imaginary dangers from abroad."
> > > > > - James Madison, 4th US president (1751-1836)
> > > > >
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
>
>