[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
YK,
An offer of level 1.3 is just an offer, it is not necessarily what the
device can do. The reasons for offering a lower level can be due to
multiple reasons, like some configuration of the terminal and not based on
encoder/decoder performance.
Having said that I would like to point out that in most cases you can get
higher functionality by using other parameters like offering level 3.1 and
using max-fs, max-br and max-cpb parameter to offer support for HD picture
(using max-fs and max-cpb) at higher bit rate (based on max-br) which are
over level 3.1 according to table A-1 in H.264. This is very typical in
video conferencing applications if the offerer cannot support the maxBR for
level 4 in table A-1.
I think that in this case it is reasonable for the answer to signal level 4
since it gives similar resolution but hinting that it can encode and decode
higher bit rate. This will not break interoperability and make it simpler
for the answerer.
Roni
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Ye-Kui
Wang
Sent: Wednesday, May 20, 2009 7:07 PM
To: 'Randell Jesup'
Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; 'stephen botzko'; avt at ietf.org
Subject: Re: [AVT] Q for 3984bis-06
Typo: encoded -> decode. So, the sentence should be as follows.
" The whole point is, if the offer contians level 1.3 (per 3984 or the bis
draft) with sendrecv or no direction attribute, then level 1.3 is the
highest it can both encoded and encode. In this case, it simply cannot
encode above level 1.3. "
BTW, it is not absolutely prohibited to change the semantics of
profile-level-id, I am just saying that you need to change the semantics. In
addition, if the encoding/sending capability and the decoding/receiving
capability is different, both capabiilties should be expressed. One way is
to use different direction attributes (and separate SDP), which was
considered not perfect. The other way is, as I mentioned earlier, to use two
parameters, one for each.
BR, YK
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> Behalf Of Ye-Kui Wang
> Sent: Wednesday, May 20, 2009 11:52 AM
> To: 'Randell Jesup'
> Cc: ron.even.tlv at gmail.com; 'stephen botzko'; avt at ietf.org;
> 'Tom Taylor'
> Subject: Re: [AVT] Q for 3984bis-06
>
>
> > For example, if the offer is 1.3 with
> level-upgrade-allowed=1, and the
> > answer is level 3.1, then the offerer can send at any level
> up to and
> > including level 3.1. It could send level 2.0 if that's the
> highest it
> > can encode.
>
> The whole point is, if the offer contians level 1.3 (per 3984
> or the bis
> draft) with sendrecv or no direction attribute, then level
> 1.3 is the highest it can both encoded and encode. In this
> case, it simply cannot encode above level 1.3.
>
> Text in 3984:
> If the profile-level-id parameter is used for
> capability exchange or session setup
> procedure,
> it indicates the profile that the codec
> supports and the highest level
> supported for the signaled profile.
>
> BR, YK
>
> > -----Original Message-----
> > From: Randell Jesup [mailto:rjesup at wgate.com]
> > Sent: Wednesday, May 20, 2009 1:08 AM
> > 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:
> > >> So, to summarize, if in response to an offer with
> > >> level-upgrade-allowed=1, the answer includes a level
> > higher than the
> > >> offerer supports:
> > >>
> > >> * The offerer can encode a stream as if it's a higher
> > level (including
> > >> parameter sets), but using the encode settings of a
> > lower level that
> > >> it supports.
> > >
> > >So, in your interpretation, the offerer sending a higher
> level just
> > >means that it sends sequence parameter sets containing the higher
> > >level, but the bitstream characteristics are still
> restricted by the
> > >lower level. How could this bring any practical usefulness? In the
> > >example, offer includes level B (e.g. spatial resolution up
> > to QVGA),
> > >and the answer includes a higher level C (e.g. spatial
> > resolution up to
> > >VGA), then both sides still send and receive up to QVGA
> > resolution, but
> > >the offer includes sequence parameter sets include the level
> > value C. Why is this useful at all?
> >
> > You asked a different question:
> >
> > >> >Now with the correct reading of the table. Again, that
> > just makes a
> > >> >difference on receiving or sending capability, not the
> > conclusion.
> > >> >You are basically assuming that the offerer's sending (i.e.
> > >> >encoding) capability is not limited, i.e. it can send
> > whatever high
> > >> >level the answer may include. How can that assumption
> be correct?
> >
> > You asked about sending at "whatever high level the answer may
> > include".
> > My response shows that you don't have to send at an
> arbitrarily-high
> > level
> > - you can send at the highest level you support.
> >
> > For example, if the offer is 1.3 with
> level-upgrade-allowed=1, and the
> > answer is level 3.1, then the offerer can send at any level
> up to and
> > including level 3.1. It could send level 2.0 if that's the
> highest it
> > can encode.
> >
> > >BR, YK
> > >
> > >> -----Original Message-----
> > >> From: Randell Jesup [mailto:rjesup at wgate.com]
> > >> Sent: Wednesday, May 20, 2009 12:29 AM
> > >> 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 shortened the text.
> > >> >
> > >> >> If the offerer is legacy, then they don't include
> > >> >> level-upgrade-allowed, and as stated the answerer is not
> > >> allowed to
> > >> >> upgrade the level. If the answerer is legacy, then they
> > >> will ignore
> > >> >> level-upgrade-allowed, and won't upgrade the level. So
> > >> those 3 cases are all handled.
> > >> >
> > >> >OK. But it is possible that the answerer is new but does
> > not want to
> > >> >upgrade the level in an offer/answer process. It would be
> > certainly
> > >> >useful that the answerer lets the other side know whether it
> > >> is new or
> > >> >legacy. Therefore, I'd prefer to include
> > >> level-upgrade-allowed equal to
> > >> >1 if the device is new (does understand the parameter and
> > >> allows level
> > >> >upgrade). Note that something is allowed does not mean it
> > is in use.
> > >>
> > >> The answerer could do that, and I don't have a problem
> with it (it
> > >> doesn't hurt anything), but I don't see how it's useful
> in any way.
> > >>
> > >> >> >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.
> > >> >>
> > >> >> No, unless we decide to take the option mentioned in my
> > >> table (change
> > >> >> it to "level-asymmetry-allowed"). Then (and only then)
> > could the
> > >> >> offerer could receive a level above what they offered.
> > >> >
> > >> >Sorry, I mis-read your table. But that just makes a
> difference on
> > >> >receiving or sending capability, not the conclusion. In the
> > >> righ case
> > >> >in the table (i.e. offer includes B, and answer
> includes C). The
> > >> >current semantics say that the offerer would only be able to
> > >> send B and
> > >> >lower. But you want the offerer to be able to send C which
> > >> is higher than B.
> > >>
> > >> I don't understand what you're trying to say here. That's
> > the point
> > >> of level upgrade. And the offerer is still sending at a level
> > >> specified in the answers profile-level-id.
> > >> Perhaps you're just saying "yes, this means the offerer
> > might end up
> > >> sending a stream at a higher level than it offered",
> which is the
> > >> whole point of level upgrade.
> > >>
> > >> >> >> 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?
> > >> >>
> > >> >> Then they shouldn't answer with "C". They should answer with
> > >> >> whatever level they do support. The point of this is
> > to allow the
> > >> >> answerer to offer to receive a higher level; they get to
> > >> choose what
> > >> >> that level is.
> > >> >
> > >> >Now with the correct reading of the table. Again, that
> > just makes a
> > >> >difference on receiving or sending capability, not the
> > >> conclusion. You
> > >> >are basically assuming that the offerer's sending (i.e.
> encoding)
> > >> >capability is not limited, i.e. it can send whatever high
> > >> level the answer may include.
> > >> >How can that assumption be correct?
> > >>
> > >> You need to think about how level works in H.264.
> > >>
> > >> Remember we're only changing level, not constraints or profiles.
> > >>
> > >> Levels imply details about the maximum frame size, maximum
> > >> macroblocks per second, maximum bitrate, etc, and each
> level is a
> > >> superset of the next-lower level. Using a level doesn't
> > mean you (as
> > >> an encoder) have to hit those maximums. If you encode a
> > stream using
> > >> the parameters of a lower level (i.e.
> > >> using lower maximums), it's decodable by a higher-level
> > decoder, even
> > >> if you set the parameter sets to the higher level.
> > >>
> > >> Even more importantly, there's no apparent requirement to send
> > >> exactly the level given by the profile-level-id; sending
> > lower levels
> > >> (with the correct profile and constraints) appears to be
> just fine
> > >> (note that this interacts with parameter-set handling -
> > you need to
> > >> deal with making sure the decoder has correct parameter
> > sets, as you
> > >> always do).
> > >>
> > >> From 3984:
> > >>
> > >> If the profile-level-id parameter is used to indicate
> > properties
> > >> of a
> > >> NAL unit stream, it indicates the profile and level
> > that a decoder
> > >> has
> > >> to support in order to comply with [1] when it decodes
> > the stream.
> > >>
> > >> and
> > >>
> > >> If the profile-level-id parameter is used for
> > capability exchange
> > >> or
> > >> session setup procedure, it indicates the profile
> that the codec
> > >> supports and the highest level supported for the
> > signaled profile.
> > >>
> > >> Note "highest level". And:
> > >>
> > >> The level conveyed in the value of the profile-level-id
> > parameter
> > >> MUST
> > >> be such that the receiver is fully capable of supporting.
> > >>
> > >> and
> > >> o Parameters used for declaring receiver capabilities are in
> > >> general
> > >> downgradable; i.e., they express the upper limit for
> > a sender's
> > >> possible behavior. Thus a sender MAY select to set
> > its encoder
> > >> using only lower/lesser or equal values of these
> parameters.
> > >> [snip]
> > >> o Parameters declaring a configuration point are not
> > downgradable,
> > >> with the exception of the level part of the
> > "profile-level-id"
> > >> parameter. This expresses values a receiver expects
> > to be used
> > >> and must be used verbatim on the sender side.
> > >>
> > >>
> > >> So, to summarize, if in response to an offer with
> > >> level-upgrade-allowed=1, the answer includes a level
> > higher than the
> > >> offerer supports:
> > >>
> > >> * The offerer can encode a stream as if it's a higher
> > level (including
> > >> parameter sets), but using the encode settings of a
> lower level
> > >> that it
> > >> supports.
> > >> * The offerer can encode a stream using a lower level, including
> > >> lower-level parameter sets.
> > >>
> > >> In both cases, the parameter sets must be conveyed to the
> > answerer in
> > >> some manner; the mechanisms that would make the most sense are
> > >> in-band parameter sets (with all that implies), or using
> > >> sprop-level-parameter-sets including levels above the
> level in the
> > >> offered profile-level-id, so that the answer can select
> > one of those
> > >> levels and thus install those parameter sets.
> > >>
> > >> None of this requires any further modification to 3984bis
> > that I can
> > >> see - just allowing level-upgrade-allowed (or
> > >> level-asymmetric-allowed).
> > >>
> > >> --
> > >> 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)
> > >>
> > >>
> >
> >
> > --
> > 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
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt