Re: [AVT] Q for 3984bis-06

[Randell Jesup <rjesup at wgate.com>]

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)