Re: [AVT] Q for 3984bis-06

[Randell Jesup <rjesup at wgate.com>]

Ye-Kui Wang <yekuiwang at huawei.com> writes:
>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.

How about this (may need a little wordsmithing):

   Level upgrade

   An offerer who wishes to allow level-upgrade in the answer can include
   "max-level=XX" in the fmtp line (XX is the level in hex, as it is in the
   middle of profile-level-id).  An answerer may not increase the level in
   the response unless the offerer included max-level, and may not increase
   the level beyond XX.  Other receive fmtp parameters such max-fs, etc
   shall apply to all levels and SHOULD not be lower than the minimum
   values required by the level specified in max-level.

And add max-level to the list of fmtp params.

Normal requirements for sprop-parameter-sets/sprop-level-parameter-sets
would apply, or in-line as per normal.

Simple, will not break any 3984 (or current 3984-bis) answerer.

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

That use-case doesn't *need* upgrade, agreed..  The one that does (or where
you gain an advantage from) is the inverse case, where something limits the
size/etc an offerer wants to decode.

Here's the relevant case: Assume this is a a device with a fixed LCD size,
or configured to play in a small window on a larger display.
------------------------
Assume the video device A is only reasonably able to decode level 2.0, due
to display limitations (QCIF LCD), but can encode up to level 3.1.
B is capable of both decoding and encoding level 3.1. 
A would quote a level of 2.0 in its offer, including max-level=1F
B would respond with level 3.1 in the answer
A would send to B video stream at level 3.1
B would send level 2.0 to A since A can only decode up to level 2.0

Otherwise, A would either need to only offer 2.0 (and only send 2.0), even
if it has an HD camera and the destination is an HD room conference system
that can display level 5.0.

You can't set max-fs lower than the min for the level offered, nor
max-mbps, so you can't limit the received bitstream in that manner.  In
theory you might be able to limit the received bitstream crudely via
b=AS:NN, but that's up to the sender to notice, comply with, and even then
it doesn't mean they won't send "too large" a framesize at a lower
framerate or higher quantization.

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