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