[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
Ye-Kui Wang <yekuiwang at huawei.com> writes:
>> 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.
>>
>
>For backward compatibility. Inclusion of level-upgrade-allowed to 1 (or
>another parameter) indicates that an entity is not a legacy device which
>does not understand the new parameter. Otherwise, you have to make sure that
>the mechanism works in all the four cases:
>
>offerer answerer
>new new
>new legacy
>legacy new
>legacy legacy
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.
>Note that these are orthogonal to the three cases your listed below.
>Basically all the 12 cases (and there are other dimentions of variations,
>e.g. the last point I made in this email) must be well analyzed for such a
>seemingly non-backward-compatible change.
Please see above. Those additional cases are all covered.
>> >> 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 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.
>> The answerer may *receive* a stream up to the level they put in the
>> answer. That's the whole point here.
>
>This point is contradicting with other places, where the answerer may
>receive a stream up to the level in the offer (not in the answer).
Heh? In current 3984/3984bis usage, if the offer is level 2.0, and the
answer is level 1.0, how will the answerer receive anything above level
1.0? Even in my proposal that's not allowed (unless we decide to use
level-asymmetry-allowed instead of level-upgrade-allowed).
>> >> 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
>>
>
>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.
>BR, YK
>
>> *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)
>>
>>
--
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)