[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
Inline.
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Tuesday, May 19, 2009 3:00 PM
> To: Ye-Kui Wang
> Cc: 'stephen botzko'; ron.even.tlv at gmail.com; 'Tom Taylor';
> avt at ietf.org
> Subject: Re: [AVT] Q for 3984bis-06
>
> 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
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.
> >> 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.
> 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).
> >> 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?
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)
>
>