Re: [AVT] Q for 3984bis-06

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

> 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)
> 
>