[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
> 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.
In that case, sprop-* parameters indicate stream properties, others indicate
basically receiving capabilities (I guess this is what you mean by SDP's
standard receive-side semantics). If someone wants to indicate sending
capabilities, then another group of parameters is needed. Hmm, this way it
may work better, but it seems too late to do this now, maybe for future
codecs.
BR, YK
> -----Original Message-----
> From: Jonathan Lennox [mailto:jonathan at vidyo.com]
> Sent: Tuesday, May 19, 2009 11:52 AM
> To: Randell Jesup; Ye-Kui Wang
> Cc: ron.even.tlv at gmail.com; Tom Taylor; avt at ietf.org
> Subject: 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
>
>