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