[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
YK,
The semantics of the parameters now is correct, what I was saying is that
there may be a difference between what a device is offering and what the
device can do in terms of processing, this can happen due to other decisions
like configuration and it may go higher if the other side indicates that it
can do so.
I think allowing level upgrade by the answerer is what all the people
discussing the topic draft are suggesting (Ingemar, Randell, Jonathan,
Magnus and others). I just gave another example where it can happen.
Maybe clarify that the level is a receive capability will help.
Jonathan Lennox even suggests " 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."
Roni Even
-----Original Message-----
From: Ye-Kui Wang [mailto:yekuiwang at huawei.com]
Sent: Wednesday, May 20, 2009 8:25 PM
To: 'Roni Even'; 'Randell Jesup'
Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; 'stephen botzko'; avt at ietf.org
Subject: RE: [AVT] Q for 3984bis-06
Roni,
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Wednesday, May 20, 2009 12:41 PM
> To: 'Ye-Kui Wang'; 'Randell Jesup'
> Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; 'stephen botzko';
> avt at ietf.org
> Subject: 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.
>
If this is the case, then the current semantics of profile-level-id is
simply incorrect as it reads.
> 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.
Correct.
> 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.
I don't think this is correct according to either RFC 3984 or the bis. As
you said earlier, it is allowed to signal level 3.1, and to use those max-*
parameters to indicate that the device has higher than 3.1 capability in a
particular aspect, but not the other way round. If you signal level 4, there
is no way to tell which aspect of the capability is lower than level 4. This
is simply not what the spec says. If you think this way should be supported,
you must propose it and make it said in the spec.
BR, YK
>
> 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
>
>