Re: [AVT] Q for 3984bis-06

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

Inline below. 

> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com] 
> Sent: Monday, May 18, 2009 2:46 PM
> To: Ye-Kui Wang
> Cc: 'Tom Taylor'; ron.even.tlv at gmail.com; avt at ietf.org
> Subject: Re: [AVT] Q for 3984bis-06
> 
> 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.
> 

What is the semantics of max-level? Would the semantics of profile-level-id
change?

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

Decoding is different and typically decoupled from display. For example, a
mobile device may be equipped with HD recording and decoding capability, but
it needs an external HD display (e.g. a TV) to really display HD. However,
in the absence of an HD display, the device can still still decode what it
recorded but just display it in a small screen. In your example, does the
video device has the capability to decoded up to level 3.1 at all?

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

I don't understand this. 

BR,YK

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