[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Q for 3984bis-06
YK,
Does this mean that you are considering adding level upgrade but just
arguing the text?
Anyhow Tom will need to call for a consensus on the change based on the long
discussion starting with the email from Ashish (May 4th)
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 9:11 PM
To: 'Roni Even'; 'Randell Jesup'
Cc: ron.even.tlv at gmail.com; 'Tom Taylor'; avt at ietf.org; 'stephen botzko'
Subject: Re: [AVT] Q for 3984bis-06
Roni,
Right, we are discussing possible approaches to acheive level upgrade. The
hottest one has been what Randell proposed (level-upgrade-allowed), but it
seems that there is something disconnecting Randell and myself, and we are
working hard to find that out :-) I believe all the discussions are good to
help us making a fully informed decision.
BR, YK
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Wednesday, May 20, 2009 2:00 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,
>
> 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
> >
> >
>
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt