Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt

From: Roni Even <[email-masked]>
Date: Mon, 05 Apr 2010 11:05:04 +0300

Stuart,
Looking again at your question I think that I gave the wrong answer before.
H.264 says that if you support a level you also support the lower ones, it
does not discuss any specific resolution and you cannot assume a resolution.
For example if the signaled level is 2.1 the encoder can send also QCIF with
compliance with level 1.0. The level signaled is not a request for a
specific resolution.
If the receiver wants to receive a picture with a specific resolution it
should use signaling like the image attribute draft in MMUSIC or H.241 for
H.323 systems. Note that in these two drafts it discusses that the encoder
may not be able to provide the requested resolution and can provide one
closer to it in order to reduce bw on the wire and processing for scaling
and cropping

Roni

> -----Original Message-----
> From: Stuart Taylor (sttaylor) [mailto:[email-masked]]
> Sent: Thursday, February 18, 2010 5:06 PM
> To: Roni Even
> Cc: Ye-Kui Wang; [email-masked]
> Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> 
> Roni,
> 
> I guess I'm having trouble with the semantics.  Consider the statement:
> "For either receiving or sending, all levels that are lower than the
> highest level supported MUST also be supported."  For the sender, is
> this only saying that the encoder must not violate the negotiated
> constraints by, for instance, sending 720p to a level 2.0 receiver?  If
> so, that seems like a convoluted way to express the requirement.
> 
> Put another way, does this mean that an encoder that only produces
> 720p,
> CIF or QCIF, with the QCIF compliant with level 1.0, is fully compliant
> provided it doesn't violate the receiver's advertised level?
> 
> Stuart
> 
> 
> 
>  -----Original Message-----
> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, February 18, 2010 4:05 AM
> To: Stuart Taylor (sttaylor)
> Cc: 'Ye-Kui Wang'; [email-masked]
> Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> 
> Hi Stuart,
> 
> About
> "First, it's common for an endpoint to have a lower
> resolution camera than display.  In that case it may negotiate for the
> display and then send at a lower level.  This works even if level
> asymmetry is not supported by the other endpoint"
> 
> this is allowed since the negotiated level define a maximum and not
> precise
> values. The decoder should be able to scale (up or down) to the display
> it
> is using.
> Yet the encoder does not send at lower level, it still supports the
> negotiated  level but is sending at lower operation point. Sending at
> lower
> level can be achieved by defining a sendonly and recvonly m lines.
> Roni
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Stuart Taylor (sttaylor)
> > Sent: Wednesday, February 17, 2010 4:50 PM
> > To: Ye-Kui Wang; [email-masked]
> > Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> >
> > YK & BR,
> >
> > Thank you for your consideration.  Some responses in line.
> >
> > Stuart
> >
> >
> > -----Original Message-----
> > From: Ye-Kui Wang [mailto:[email-masked]]
> > Sent: Tuesday, February 16, 2010 6:28 PM
> > To: Stuart Taylor (sttaylor); [email-masked]
> > Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> >
> >
> >
> > Hi Stuart,
> >
> > Thanks for your new comments. Please see my replies below.
> >
> > > ---
> > >
> > > Page 41, 2nd paragraph, says:
> > >          "If the profile-level-id parameter is used to indicate
> > >           properties of a NAL unit stream, it indicates that,
> > > to decode
> > >           the stream, the minimum subset of coding tools a decoder
> > has
> > >           to support is the default sub-profile, and the lowest
> level
> > >           the decoder has to support is the default level."
> > >
> > > I think that should say "[...], and the *highest* level the
> > > decoder has to support [...]"
> > >
> >
> > No, the original text is correct. Decoders that are more powerful can
> > decode
> > bitstreams that require less powerful decoders. For example, a
> > bitstream
> > marked as level 1 requires that the lowest level a decoder has to
> > support is
> > level 1. A decoder supporting level 2 also satisfies the requirement.
> >
> > [ST] I still find this text to be confusing: "and the lowest level
> the
> > decoder has to support is the default level" implies the decoder
> > doesn't
> > have to support any level below the default level and might need to
> > support a level higher than the default level.
> >
> > > ---
> > >
> > > In the next paragraph:
> > >          "[...] For either
> > >           receiving or sending, all levels that are lower than the
> > >           highest level supported MUST also be supported."
> > >
> > > I think that should say "[...] For receiving, all levels
> > > [...]".  As currently worded this indicates the encoder must
> > > support all levels below the negotiated one.  However, since
> > > the level is always downgradeable, it should be sufficient to
> > > encode any one level that is equal to or less than the
> > > negotiated level.  In contrast, it is important for a decoder
> > > to handle all levels below the maximum.
> > >
> >
> > So you think there are good encoders that can encode level 2
> bitstreams
> > but
> > cannot encode level 1 bitstreams?
> >
> > In any case, if we make the change here by removing "or sending",
> then
> > the
> > level downgrading feature would be problematic. For example, when the
> > offerer offers level 2, while the answerer answers level 1, without
> the
> > presence of the parameters newly defined in the bis draft in either
> the
> > offer or the answer, then level 1 is used in both directions. This
> can
> > only
> > work based on that the offerer can encode the offered level (2) and
> any
> > lower level.
> >
> > [ST] Actually, a lot of encoders support a subset of levels, for at
> > least two reasons.  First, it's common for an endpoint to have a
> lower
> > resolution camera than display.  In that case it may negotiate for
> the
> > display and then send at a lower level.  This works even if level
> > asymmetry is not supported by the other endpoint. Second, it's
> > expensive
> > to test the full set of levels, particularly if there is no perceived
> > market need for all of them.  As long as the encoder can support
> level
> > 1.0, it should be compliant with the requirement.  Support of
> anything
> > higher should be based on perceived market need rather than forced by
> > standards.
> >
> > > ---
> > >
> > > Page 42, bottom paragraph says:
> > >           "If a receiver can support all the properties of
> > > level A, the
> > >           highest level specified in the value of the profile-
> level-
> > id
> > >           parameter or the max-recv-level parameter MUST be level A
> > >           (i.e. MUST NOT be lower than level A).  In other words, a
> > >           receiver MUST NOT signal values of max-mbps,
> > > max-fs, max-cpb,
> > >           max-dpb, and max-br that taken together meet the
> > > requirements
> > >           of a higher level compared to the highest level specified
> > in
> > >           the value of the profile-level-id parameter or the max-
> > recv-
> > >           level parameter."
> > >
> > > The first sentence goes beyond a prohibition against using
> > > the optional parameters inappropriately: it further requires
> > > a level advertisement to always indicate the maximum level
> > > that can be decoded.  I don't think that further requirement
> > > is necessary, and is certainly not enforceable.
> > >
> > > I suggest the following alternative:
> > >
> > >           These optional parameters MUST NOT be used to advertise
> the
> > >           capability to receive at a level higher than indicated by
> > >           the max-recv-level or profile-level-id parameters.
> > > In other words,
> > >           if a receiver advertises level A with max-recv-level or
> > >           profile-level-id, and the receiver is fully capable
> > > of decoding
> > >           a higher level B, the receiver MUST NOT signal
> > > values of max-mbps,
> > >           max-fs, max-cpb, max-dpb, and max-br that taken
> > > together meet all
> > >           the requirements of level B.
> >
> > This was originated from RFC 3984. To me this restriction is
> reasonable
> > - it
> > forces the profile-level-id to tell the truth. It does not make sense
> > to
> > me
> > to label a decoder capable of decoding level 2 bitstreams with level
> 1.
> > BTW,
> > why this restriction is not enforceable?
> >
> > [ST] I agree it is in RFC 3984.  It's not enforceable (or detectable)
> > because the maximum capabilities are not exposed unless the endpoint
> > chooses to do so.  There is no interoperability benefit to this
> > prescription beyond what market forces are likely to require, so I
> > would
> > choose to leave this up to endpoint vendors to decide.
> >
> > Note that advertising a lower level can be a useful tool for adapting
> > to
> > a variety of conditions.  It may be, for example, that a receiver
> would
> > want to force the level down to 2.0 (CIF) in favor of having to
> support
> > streams coming in at an intermediate level if conditions don't allow
> > level 3.1 (720p).
> >
> > > ---
> > >
> > > Page 67, top paragraph, says:
> > >    "Parameters declaring a configuration point are not
> > > changeable, with
> > >    the exception of the level part of the "profile-level-id"
> > parameter
> > >    for unicast usage.  This expresses values a receiver expects to
> be
> > >    used and must be used verbatim on the sender side."
> > >
> > > I suggest changing "This expresses" to "These express".  That
> > > should make it clearer that the second sentence refers to the
> > > configuration point parameters (plural) rather than the level
> > > (singular).
> > >
> >
> > Agreed.
> >
> > > ---
> > >
> > > When there are multiple offers in an m-line, is it required
> > > that all formats are distinguishable by a difference in a
> > > configuration point parameter (again, excluding the level)?
> > > I think it should be required, but I don't see where it is
> > > stated.  I suggest:
> > >
> > >         When multiple configuration offers are made, they
> > > MUST be distinguishable
> > >         by differences in the packetization mode and/or
> > > profile-level-id, excluding the
> > >         level part of the profile-level-id.
> > >
> >
> > I think it is good not to have this restriction, as different offers
> > may
> > differ by other parameters as well, e.g. those buffering parameters
> for
> > the
> > interleaved packetization mode.
> >
> > [ST] In that case the position should be stated and we should have
> > clear
> > rules for how to match answers to offers that take this into account.
> > Note that this creates a potential ambiguity if the same PT is not
> > usable in an answer.  Currently it is permissible to answer with a
> > different PT and then the configuration point parameters are used to
> > create the match.  An example of a troublesome case is where a B2BUA
> > (such as Cisco Unified Communications Manager) is trying to match
> > capabilities between two offers with conflicting PT numbers.
> >
> > BR, YK
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Mon, 5 Apr 2010 10:29:25 -0500

Thanks Roni.

My understanding is consistent with what you just said.  The disconnect
is with the requirement that an encoder must support all levels below
the advertised one.  It seems to me that if the encoder only supports
levels 3.1 and 1.0, and therefore encodes at level 1.0 if level 3.0 is
negotiated, it should still be compliant.

Stuart

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Monday, April 05, 2010 4:05 AM
To: Stuart Taylor (sttaylor)
Cc: 'Ye-Kui Wang'; [email-masked]
Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt

Stuart,
Looking again at your question I think that I gave the wrong answer
before.
H.264 says that if you support a level you also support the lower ones,
it
does not discuss any specific resolution and you cannot assume a
resolution.
For example if the signaled level is 2.1 the encoder can send also QCIF
with
compliance with level 1.0. The level signaled is not a request for a
specific resolution.
If the receiver wants to receive a picture with a specific resolution it
should use signaling like the image attribute draft in MMUSIC or H.241
for
H.323 systems. Note that in these two drafts it discusses that the
encoder
may not be able to provide the requested resolution and can provide one
closer to it in order to reduce bw on the wire and processing for
scaling
and cropping

Roni

---

From: stephen botzko <[email-masked]>
Date: Mon, 5 Apr 2010 11:37:48 -0400

Yes, the levels are hierarchical (level 1.0 is a subset of level 3.0, etc).

However profiles are not (in general) hierarchically structured, so a bit
stream that is compliant to the H.264 Baseline Profile might not be
compliant with the Main or High Profiles.

Stephen Botzko