Re: [AVT] Q for 3984bis-06

[Randell Jesup <rjesup at wgate.com>]

Ye-Kui Wang <yekuiwang at huawei.com> writes:
>I see immediately the following problems with the semantics, without yet
>considering all possible cases. 
>
>>   level-upgrade-allowed=0 or 1:
>>          If the offer sets level-upgrade-allowed to 1, then an answer
>>          may include any level above the offered level in
>>          profile-level-id.
>
>Only when the offer and the answer both include level-upgrade-allowed equal
>to 1, it is allowed for the answer to include a higher level. In all other
>cases, level upgrade is not allowed. 

Why is level-upgrade-allowed required in the response?  The level upgrade
is signaled (or not) via the profile-level-id value returned in the answer;
there's no need for an additional parameter in the answer.  

>>          The offerer may send at any level up to the level in the
>>          answer,
>
>This does not work with the current semantics of profile-level-id (part of
>which copied below for convenience). 
>
>"The profile-level-id parameter indicates the default sub-profile, i.e. the
>subset of coding tools that may have been used to generate the stream or
>that the receiver supports, and the default level of the stream or the
>receiver supports."
>
>According to the current semantics of profile-level-id, the level part of
>the profile-level-id in the offer limits what the offerer can receive. 

Right...  That doesn't change; there's no conflict here.  The answerer
answers with a higher level, but the answerer is still not allowed to
*send* a level above that provided in the offer.  The answerer may
*receive* a stream up to the level they put in the answer.  That's the
whole point here.

>>        and and answerer can send levels only up to the level in the
>>        offer.  
>
>What if the answerer has a receiving capability between the two levels in
>the offer and the answer or lower than the level in the offer, and it wants
>the receiving capability expressed?

Using level-upgrade-allowed=1 (the current proposal) means there is only
one level in the offer (profile-level-id).  If the answerer wants to
downgrade the level in the response, they may do so (as per current),
regardless of level-upgrade-allowed.  If they want to upgrade it, they can
pick whatever level they're willing to receive and respond with that.  They
will send the level in the offer (or below).

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

*This could be 'B' if we decide the same asymmetry is allowed for
level-downgrade as well, when level-upgrade-allowed=1.  (We could rename it
level-asymmetry-allowed if we want that ability.)


Current behavior, and if there's no level-upgrade-allowed (or it's 0):

 Answer level:     lower (A)       same (B)       higher (C)

Offerer can send:     A              B             Not Allowed
Answerer can send:    A              B             Not Allowed


>BR, YK
>
>
>> If this is not present or is set to 0, then 
>> the answer
>>          MUST NOT respond with a level greater than the level in
>>          profile-level-id.  
>> 
>>          Note that this only allows the level to be increased in the
>>          answer; the profile and constraints are not allowed to change.
>> 
>
>> -----Original Message-----
>> From: Randell Jesup [mailto:rjesup at wgate.com] 
>> Sent: Tuesday, May 19, 2009 12:24 PM
>> To: stephen botzko
>> Cc: Ye-Kui Wang; ron.even.tlv at gmail.com; Tom Taylor; avt at ietf.org
>> Subject: Re: [AVT] Q for 3984bis-06
>> 
>> stephen botzko <stephen.botzko at gmail.com> writes:
>> >>>>
>> >This is a real-world case; devices often have more encode horsepower 
>> >(and camera resolution) than they can actually display when 
>> receiving, 
>> >and they talk to other devices that *can* display that extra 
>> resolution..
>> >>>>
>> >
>> >In our experience, the reverse situation is what actually happens - PCs
>> >for instance frequently can decode and display HD images, but are often
>> >limited to an SD webcam.  Can you name a couple of specific real
>> >devices that have these HD cameras+encoders and the limited decoders?
>> 
>> Mostly I'm not talking PC's (I agree with you there, though 
>> there are cases where it still may make sense, like when 
>> displaying video in a portion of the screen).  I'm mostly 
>> talking mobile and dedicated devices with built-in LCDs; that 
>> would include Smartphones, dedicated videophones, "media"
>> tablets, etc.
>> 
>> For example, certain devices have been made with two 
>> different LCDs; one ~850x480, the other ~480x234, both with 
>> VGA-class cameras.  Sending VGA content (or really anything 
>> beyond CIF) to the 480x234 display is just a waste of bits.  
>> If you wanted to and could negotiate it properly, though, you 
>> could send higher framerate CIF to that device, while it 
>> sends VGA at a lower framerate to a device that can show it.
>> 
>> 
>> As for the comment about max-level=NN versus 
>> level-upgrade-allowed: I'd originally thought 
>> level-upgrade-allowed made the most sense, and in fact 
>> probably it does - let the answer respond with the highest 
>> level they can receive, and the offerer can send at whatever 
>> level they support.  
>> 
>> That's even easier to describe:
>> 
>>   level-upgrade-allowed=0 or 1:
>>          If the offer sets level-upgrade-allowed to 1, then an answer
>>          may include any level above the offered level in
>>          profile-level-id.  The offerer may send at any level up to the
>>          level in the answer, and and answerer can send levels only up
>>          to the level in the offer.  If this is not present or is set to
>>          0, then the answer MUST NOT respond with a level greater than
>>          the level in profile-level-id.
>> 
>>          Note that this only allows the level to be increased in the
>>          answer; the profile and constraints are not allowed to change.


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