[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
Why is max-level (with a value) needed, as opposed to something like
level-upgrade-allowed? Remember the level sent by a receiver is still
only an upper bound on what the transmitter is allowed to send.
Architecturally, I think it would be cleanest if H.264's non sprop-*
parameters all have SDP's standard receive-side semantics, rather than
offer/answer semantics.
--
Jonathan Lennox
Vidyo, Inc
jonathan at vidyo.com
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Tuesday, May 19, 2009 10:58 AM
> To: Ye-Kui Wang
> Cc: 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:
> >> 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?
>
> max-level is an offerer-only parameter, since it's used by the
receiver
> to
> generate an answer. It does not change the semantics of
profile-level-
> id
> (beyond that an answer can use a higher level).
>
> >> 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?
>
> The video device may have the *capability* to decode level 3.1 (in
> terms of
> raw horsepower), but it may not have the capability to both decode and
> scale
> it down, and more importantly it may not want to use up the bandwidth
> and
> horsepower (at the sender and on the network, and/or it's own battery
> power) to receive HD when it can only display a much smaller
> resolution.
>
> Think of a battery-powered device w/ 802.11. Why spend the bandwidth
> on
> the air to receive HD, and the battery power to decode and scale HD,
> when
> you're displaying 640x480 (or lower)? You still may want to send HD
if
> you're calling into an HD conference room or HD-capable endpoint.
> Also, in
> a multi-party conference situation, the conference server will want to
> minimize bits sent and horsepower for encoding streams, so this may be
> a
> win.
>
> On a more general level, what was the purpose in not allowing upgrade
> in
> the first place? I think it wasn't explicit; originally neither
> downgrade
> nor upgrade were allowed, and downgrade was dealt with first because
> there
> are obvious and more-common uses for downgrade.
>
> This should have *no* impact on existing implementations; you can
> safely
> ignore max-level when making an answer.
>
> >> 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.
>
> If you offer level 2.1, you are not allowed to use max-fs/etc to
> restrict
> the received bitstream to a lower framesize/etc than level 2.1
> supports.
> You can only increase the framesize/etc over the level offered:
>
> The value of max-fs MUST be greater than or equal to the value of
> MaxFS
> for the level given in Table A-1 of [1].
>
> So you can't say "I support level 2.2 but I only want to receive a
> framesize of CIF (the max size in level 2.0)". Level 2.2 would allow
> receiving CIF at ~50fps; if you offer level 2.0 instead, the answerer
> can't
> send you anything beyond 30fps. But you can't offer 2.2 without
> allowing
> the answerer to send you 4CIF at 12fps, which you would just have to
> scale
> down to CIF anyways.
>
> 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..
>
> --
> 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)
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt