Re: [AVT] Q for 3984bis-06

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

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

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