[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
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.
> 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.
> 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?
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)
>
>