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

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Tue, 16 Feb 2010 15:20:21 -0600

A few minor comments on the latest draft. Apologies for not going
through this more carefully before.

Stuart Taylor
Cisco Systems

---

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 [...]"

---

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.

---

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.

---

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

---

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.

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 16 Feb 2010 18:27:30 -0500

Hi Stuart,

Thanks for your new comments. Please see my replies below. 

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

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

> 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.
>
>           the max-recv-level or profile-level-id parameters. 
> In other words,
>           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

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?

> 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

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. 

BR, YK

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stuart Taylor (sttaylor)
> Sent: Tuesday, February 16, 2010 4:20 PM
> To: [email-masked]
> Subject: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> 
> A few minor comments on the latest draft. Apologies for not 
> going through this more carefully before.
> 
> Stuart Taylor
> Cisco Systems
> 
> ---
> 
> I think that should say "[...], and the *highest* level the 
> decoder has to support [...]"
> 
> ---
> 
> In the next paragraph:
>          "[...] For either
> 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.
> 
> ---
> 
> 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.
>           the max-recv-level or profile-level-id parameters. 
> In other words,
>           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
> 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).
> 
> ---
> 
> 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
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Wed, 17 Feb 2010 08:50:09 -0600

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,

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

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

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

Agreed. 

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

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 17 Feb 2010 11:07:43 -0500

Stuart,

"BR" is abbreviation of "Best Regards" :-)

See my replies inline below.

BR, YK

> From: Stuart Taylor (sttaylor) [mailto:[email-masked]] 
> Sent: Wednesday, February 17, 2010 9:50 AM
> To: Ye-Kui Wang; [email-masked]

I don't see the the implication here. If a decocer supports level 2, it is
required to support any level lower than level 2, as specified by the video
coding standard specification. 

> asymmetry is not supported by the other endpoint. Second, 

In this case you may encoder at a lower level but has a higher decoding
capability. I don't see this closely relates to our discussion point here
(whether an encoder supports level 2 should also support level 1).

> it's expensive
> to test the full set of levels, 

True here. But I don't think people would like to totally remove the level
downgrade feature. 

> particularly if there is no perceived
> market need for all of them.  

> As long as the encoder can support level

I don't understand the last two sentences above. Again, our discussion point
here is whether an encoder supports level 2 should also support level 1.

> chooses to do so.  

Being enforceable to me means that it is testable. This restriction is
certainly testable. 

> There is no interoperability benefit to this
> prescription beyond what market forces are likely to require, 

I don't understand this point. What are exactly the market forces are likely
to require here?

> so I would

I don't see the benefit. Could you please give a concrete use case wherein
this shows benefit?

> capabilities between two offers with conflicting PT numbers.

If there are multiple options offered and the answerer chooses one of them,
then everything is clearly decided. If the PT is different, then the match
should be done based on other parts of the offer and the answer, including
the configuration parameters and the buffering parameter(s), when present,

---

From: Roni Even <[email-masked]>
Date: Thu, 18 Feb 2010 11:04:50 +0200

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stuart Taylor (sttaylor)
> Sent: Wednesday, February 17, 2010 4:50 PM
> Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> 
> YK & BR,
>

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Thu, 18 Feb 2010 09:06:09 -0600

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

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

---

From: Roni Even <[email-masked]>
Date: Thu, 18 Feb 2010 21:37:48 +0200

Stuart,

The second paragraph  on profile-levl-id says

"The profile-level-id parameter indicates the default sub-profile, i.e. the
subset of coding tools that may have been used to generate the stream or
that the receiver supports, and the default level of the stream or the
receiver supports."

BTW: YK last "or" should be "that".

So the level signifies the receiver capability not the sender capability.
I think that the statement you are referencing is not correct. The decoder
must support any level lower but the sender or encoder MAY support any lower
level.
The H.264 encoder is not required to support all levels below the one
announced. I think that the point here is not about supporting a lower level
but being able to encode a picture that will be within the limits of a lower
level and the encoder MAY be able to do it but is not required by H.264. The
offer can specify the operation points supported by the encoder using the
sprop-level-parameter-sets

Look at all the three emails from Gary Sullivan about the encoder
capabilities when we discussed spatial resolution. Note that H.264 level do
not discuss resolutions supported but number of macro blocks without
specific geometry. To specify supported geometry you should use the image
attribute specified in
http://tools.ietf.org/html/draft-ietf-mmusic-image-attributes-04 maybe it
will be good to reference this draft.

Roni

> Sent: Thursday, February 18, 2010 5:06 PM
> To: Roni Even
> Cc: Ye-Kui Wang; [email-masked]
> > >           highest level specified in the value of the profile-
> level-
> > id

Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
From: Gary Sullivan <[email-masked]>
To: "Even, Roni"@huawei.com, [email-masked]
Date: Mon, 14 Jul 2008 11:05:01 +0200

Maybe I'm missing some of the context of this discussion, but from the
perspective of the video codec itself, Level may not be about resolution at
all.  For example, an encoder may use a particular level just to be able to
reference more pictures in DPB capacity, not because the pictures are higher
resolution.  Or perhaps it may use a level because it wants to operate at a
higher bit rate than what a lower level would allow.  It's not necessarily a
matter of resolution at all.

Unless there is something specific to the application context, ...

-Gary

+> -----Original Message-----
+> From: [email-masked] [mailto:[email-masked]] On
+> Behalf Of Even, Roni
+> Sent: Monday, July 14, 2008 2:01 AM
+> To: [email-masked]; [email-masked]
+> Subject: Re: [AVT] spatial-resolution parameter for RFC 3984bis
+>
+> YK,
+> This is not required from the encoder to prepare a specific
+> resolution
+> or to support it. It only need to support a resolution
+> within the level
+> and not any resolution within the level.
+> Roni
+>
+> > -----Original Message-----
+> > From: [email-masked] [mailto:[email-masked]]
+> > Sent: Monday, July 14, 2008 11:54 AM
+> > To: Even, Roni; [email-masked]
+> > Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> >
+> >
+> > Roni,
+> >
+> > But why is this related to encoder scaling? The encoder can just
+> encode
+> > a bitstream with the resolution requested, without scaling. If the
+> > encoder supports Level 2.0, then it automatically supports all
+> > resolutions for which the number of MBs is not greater
+> than that for
+> > CIF
+> > (352x288), without scaling.
+> >
+> > BR, YK
+> >
+> > >-----Original Message-----
+> > >From: ext Even, Roni [mailto:[email-masked]]
+> > >Sent: 14 July, 2008 11:45
+> > >To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
+> > >Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> > >
+> > >YK,
+> > >According to H.264 the encoder does not need to scale, this is
+> > >up to the
+> > >receiver, so there is no requirement for the sender to support a
+> > >specific resolution even if it is within the level!!!!
+> > >Roni
+> > >
+> > >> -----Original Message-----
+> > >> From: [email-masked] [mailto:[email-masked]]
+> > >> Sent: Monday, July 14, 2008 11:41 AM
+> > >> To: Even, Roni; [email-masked]
+> > >> Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> > >>
+> > >>
+> > >> Roni,
+> > >>
+> > >> If the requested resolution (100x50) is supported by
+> the Level, and
+> > >the
+> > >> offerer agreed or offered the Level, then the offerer
+> MUST accept
+> > and
+> > >> send the resolution. There is no reason that a sender does
+> > >not support
+> > >> a
+> > >> certain resolution complaint to a level the sender
+> supports, right?
+> > >And
+> > >> as it is als restricted that the answerer MUST only request a
+> > >> resolution
+> > >> complaint to the agreed or offered Level (or any lower
+> Level), it
+> is
+> > >> then impossible that such a requested resolution cannot be
+> supported
+> > >by
+> > >> the offerer.
+> > >>
+> > >> If the answerer requests a resolution of a Level that
+> the offerer
+> > >> cannot
+> > >> support, the offerer has to reject anyway as it cannot
+> support the
+> > >> Level
+> > >> at the first step.
+> > >>
+> > >> BR, YK
+> > >>
+> > >> >-----Original Message-----
+> > >> >From: ext Even, Roni [mailto:[email-masked]]
+> > >> >Sent: 14 July, 2008 10:59
+> > >> >To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
+> > >> >Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> > >> >
+> > >> >YK,
+> > >> >Having an upper restriction is OK but you still do not address
+> > >> >the issue
+> > >> >of what if the sender can not supply it.
+> > >> >For example let's say that the request is for a resolution
+> > >of 100x50,
+> > >> >what will the sender do if it can not send such resolution,
+> > >should it
+> > >> >reject the request, should it send 90x40 or 110x50 if it can?
+> > >> >Roni
+> > >> >
+> > >> >> -----Original Message-----
+> > >> >> From: [email-masked] [mailto:[email-masked]]
+> > >> >> Sent: Monday, July 14, 2008 10:55 AM
+> > >> >> To: Even, Roni; [email-masked]
+> > >> >> Subject: RE: [AVT] spatial-resolution parameter for
+> RFC 3984bis
+> > >> >>
+> > >> >>
+> > >> >> Hi Roni,
+> > >> >>
+> > >> >> The resolution must be restricted by the level part of
+> > >> >profile-level-id
+> > >> >> and max-fs. Therefore, if a configuration is agreed (or
+> > >agreeable),
+> > >> >> then
+> > >> >> the answerer must request a resolution under the
+> constraint, and
+> > >the
+> > >> >> offerer must accept the request as long as it meets the
+> > >restriction.
+> > >> >> This is similar as sprop-parameter-sets, as long as it is
+> > >complaint
+> > >> >> with
+> > >> >> the agreed (or agreeable) configuration, the other side
+> > >must accept
+> > >> >it.
+> > >> >>
+> > >> >> Would it work this way?
+> > >> >>
+> > >> >> BR, YK
+> > >> >>
+> > >> >> >-----Original Message-----
+> > >> >> >From: ext Even, Roni [mailto:[email-masked]]
+> > >> >> >Sent: 14 July, 2008 10:38
+> > >> >> >To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
+> > >> >> >Subject: RE: [AVT] spatial-resolution parameter for
+> RFC 3984bis
+> > >> >> >
+> > >> >> >YK,
+> > >> >> >Just to clarify,
+> > >> >> >The text on the receiver side says that this is the
+> requested
+> > >> >> >resolution, it does not address issue of
+> negotiation, what will
+> > >the
+> > >> >> >sender do if it cannot send this resolution, should
+> it reject
+> > the
+> > >> >> >stream?.
+> > >> >> >If this is for negotiation do you except to do a new offer
+> > >> >> >answer if the
+> > >> >> >receiver wants a new resolution?
+> > >> >> >
+> > >> >> >Roni
+> > >> >> >
+> > >> >> >> -----Original Message-----
+> > >> >> >> From: [email-masked]
+> [mailto:[email-masked]] On
+> > >> Behalf
+> > >> >> Of
+> > >> >> >> [email-masked]
+> > >> >> >> Sent: Sunday, July 13, 2008 7:57 PM
+> > >> >> >> To: [email-masked]
+> > >> >> >> Subject: [AVT] spatial-resolution parameter for
+> RFC 3984bis
+> > >> >> >>
+> > >> >> >>
+> > >> >> >> Concluded from the discussions in the email threads
+> > >> >listed below, I
+> > >> >> >> added a new parameter, spatial-resolution, to the RFC
+> > >> >3984bis draft
+> > >> >> >> (which will be submitted by tomorrow):
+> > >> >> >>
+> > >> >> >>
+> http://www.ietf.org/mail-archive/web/avt/current/msg09425.html
+> > >> >> >>
+> http://www.ietf.org/mail-archive/web/avt/current/msg09650.html
+> > >> >> >>
+> > >> >> >> The parameter is specified as follows (basically
+> as Randell
+> > >> >> suggested
+> > >> >> >> in
+> > >> >> >>
+> > >http://www.ietf.org/mail-archive/web/avt/current/msg09429.html).
+> > >> >> >>
+> > >> >> >> spatial-resolution:
+> > >> >> >> This parameter MAY be used to indicate the maximum spatial
+> > >> >> resolution
+> > >> >> >> of
+> > >> >> >> a NAL unit stream or the preferred spatial resolution of a
+> > >> >receiver.
+> > >> >> >> The value is a base16 [6] (hexadecimal) representation of
+> > >> >the width
+> > >> >> >and
+> > >> >> >> height of the spatial resolution, in pixels,
+> separated by a
+> > >> comma.
+> > >> >> >>
+> > >> >> >> Usage in SDP offer/answer:
+> > >> >> >> - When "a=sendrecv" or no direction attribute is used,
+> > >> >> >> "spatial-resolution" indicates both the maximum spatial
+> > >> resolution
+> > >> >> of
+> > >> >> >> the stream sent by the declaring entity and the preferred
+> > >spatial
+> > >> >> >> resolution for receiving a stream.
+> > >> >> >> - When "a=sendonly", "spatial-resolution" indicates the
+> > maximum
+> > >> >> >spatial
+> > >> >> >> resolution of the outgoing stream.
+> > >> >> >> - When "a=recvonly", "spatial-resolution" indicates the
+> > >preferred
+> > >> >> >> spatial resolution for receiving a stream.
+> > >> >> >>
+> > >> >> >> Comments are welcome.
+> > >> >> >>
+> > >> >> >> BR, YK
+> > >> >> >> _______________________________________________
+> > >> >> >> Audio/Video Transport Working Group
+> > >> >> >> [email-masked]
+> > >> >> >> https://www.ietf.org/mailman/listinfo/avt
+> > >> >> >
+> > >> >
+> > >
+> _______________________________________________
+> Audio/Video Transport Working Group
+> [email-masked]
+> https://www.ietf.org/mailman/listinfo/avt
+>
+>

Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
From: Gary Sullivan <[email-masked]>
To: [email-masked], "Even, Roni"@huawei.com
Date: Mon, 14 Jul 2008 11:00:42 +0200

Doesn't sound true to me.  Encoders support only what they want to support.
It's decoders that have to swallow whatever they are fed, not encoders.

-Gary

+> -----Original Message-----
+> From: [email-masked] [mailto:[email-masked]] On
+> Behalf Of [email-masked]
+> Sent: Monday, July 14, 2008 1:54 AM
+> To: [email-masked]; [email-masked]
+> Subject: Re: [AVT] spatial-resolution parameter for RFC 3984bis
+>
+>
+> Roni,
+>
+> But why is this related to encoder scaling? The encoder can
+> just encode
+> a bitstream with the resolution requested, without scaling. If the
+> encoder supports Level 2.0, then it automatically supports all
+> resolutions for which the number of MBs is not greater than
+> that for CIF
+> (352x288), without scaling.
+>
+> BR, YK
+>
+> >-----Original Message-----
+> >From: ext Even, Roni [mailto:[email-masked]]
+> >Sent: 14 July, 2008 11:45
+> >To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
+> >Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> >
+> >YK,
+> >According to H.264 the encoder does not need to scale, this is
+> >up to the
+> >receiver, so there is no requirement for the sender to support a
+> >specific resolution even if it is within the level!!!!
+> >Roni
+> >
+> >> -----Original Message-----
+> >> From: [email-masked] [mailto:[email-masked]]
+> >> Sent: Monday, July 14, 2008 11:41 AM
+> >> To: Even, Roni; [email-masked]
+> >> Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> >>
+> >>
+> >> Roni,
+> >>
+> >> If the requested resolution (100x50) is supported by the
+> Level, and
+> >the
+> >> offerer agreed or offered the Level, then the offerer
+> MUST accept and
+> >> send the resolution. There is no reason that a sender does
+> >not support
+> >> a
+> >> certain resolution complaint to a level the sender
+> supports, right?
+> >And
+> >> as it is als restricted that the answerer MUST only request a
+> >> resolution
+> >> complaint to the agreed or offered Level (or any lower
+> Level), it is
+> >> then impossible that such a requested resolution cannot
+> be supported
+> >by
+> >> the offerer.
+> >>
+> >> If the answerer requests a resolution of a Level that the offerer
+> >> cannot
+> >> support, the offerer has to reject anyway as it cannot support the
+> >> Level
+> >> at the first step.
+> >>
+> >> BR, YK
+> >>
+> >> >-----Original Message-----
+> >> >From: ext Even, Roni [mailto:[email-masked]]
+> >> >Sent: 14 July, 2008 10:59
+> >> >To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
+> >> >Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> >> >
+> >> >YK,
+> >> >Having an upper restriction is OK but you still do not address
+> >> >the issue
+> >> >of what if the sender can not supply it.
+> >> >For example let's say that the request is for a resolution
+> >of 100x50,
+> >> >what will the sender do if it can not send such resolution,
+> >should it
+> >> >reject the request, should it send 90x40 or 110x50 if it can?
+> >> >Roni
+> >> >
+> >> >> -----Original Message-----
+> >> >> From: [email-masked] [mailto:[email-masked]]
+> >> >> Sent: Monday, July 14, 2008 10:55 AM
+> >> >> To: Even, Roni; [email-masked]
+> >> >> Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> >> >>
+> >> >>
+> >> >> Hi Roni,
+> >> >>
+> >> >> The resolution must be restricted by the level part of
+> >> >profile-level-id
+> >> >> and max-fs. Therefore, if a configuration is agreed (or
+> >agreeable),
+> >> >> then
+> >> >> the answerer must request a resolution under the
+> constraint, and
+> >the
+> >> >> offerer must accept the request as long as it meets the
+> >restriction.
+> >> >> This is similar as sprop-parameter-sets, as long as it is
+> >complaint
+> >> >> with
+> >> >> the agreed (or agreeable) configuration, the other side
+> >must accept
+> >> >it.
+> >> >>
+> >> >> Would it work this way?
+> >> >>
+> >> >> BR, YK
+> >> >>
+> >> >> >-----Original Message-----
+> >> >> >From: ext Even, Roni [mailto:[email-masked]]
+> >> >> >Sent: 14 July, 2008 10:38
+> >> >> >To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
+> >> >> >Subject: RE: [AVT] spatial-resolution parameter for
+> RFC 3984bis
+> >> >> >
+> >> >> >YK,
+> >> >> >Just to clarify,
+> >> >> >The text on the receiver side says that this is the requested
+> >> >> >resolution, it does not address issue of negotiation,
+> what will
+> >the
+> >> >> >sender do if it cannot send this resolution, should
+> it reject the
+> >> >> >stream?.
+> >> >> >If this is for negotiation do you except to do a new offer
+> >> >> >answer if the
+> >> >> >receiver wants a new resolution?
+> >> >> >
+> >> >> >Roni
+> >> >> >
+> >> >> >> -----Original Message-----
+> >> >> >> From: [email-masked] [mailto:[email-masked]] On
+> >> Behalf
+> >> >> Of
+> >> >> >> [email-masked]
+> >> >> >> Sent: Sunday, July 13, 2008 7:57 PM
+> >> >> >> To: [email-masked]
+> >> >> >> Subject: [AVT] spatial-resolution parameter for RFC 3984bis
+> >> >> >>
+> >> >> >>
+> >> >> >> Concluded from the discussions in the email threads
+> >> >listed below, I
+> >> >> >> added a new parameter, spatial-resolution, to the RFC
+> >> >3984bis draft
+> >> >> >> (which will be submitted by tomorrow):
+> >> >> >>
+> >> >> >>
+> http://www.ietf.org/mail-archive/web/avt/current/msg09425.html
+> >> >> >>
+> http://www.ietf.org/mail-archive/web/avt/current/msg09650.html
+> >> >> >>
+> >> >> >> The parameter is specified as follows (basically as Randell
+> >> >> suggested
+> >> >> >> in
+> >> >> >>
+> >http://www.ietf.org/mail-archive/web/avt/current/msg09429.html).
+> >> >> >>
+> >> >> >> spatial-resolution:
+> >> >> >> This parameter MAY be used to indicate the maximum spatial
+> >> >> resolution
+> >> >> >> of
+> >> >> >> a NAL unit stream or the preferred spatial resolution of a
+> >> >receiver.
+> >> >> >> The value is a base16 [6] (hexadecimal) representation of
+> >> >the width
+> >> >> >and
+> >> >> >> height of the spatial resolution, in pixels, separated by a
+> >> comma.
+> >> >> >>
+> >> >> >> Usage in SDP offer/answer:
+> >> >> >> - When "a=sendrecv" or no direction attribute is used,
+> >> >> >> "spatial-resolution" indicates both the maximum spatial
+> >> resolution
+> >> >> of
+> >> >> >> the stream sent by the declaring entity and the preferred
+> >spatial
+> >> >> >> resolution for receiving a stream.
+> >> >> >> - When "a=sendonly", "spatial-resolution" indicates
+> the maximum
+> >> >> >spatial
+> >> >> >> resolution of the outgoing stream.
+> >> >> >> - When "a=recvonly", "spatial-resolution" indicates the
+> >preferred
+> >> >> >> spatial resolution for receiving a stream.
+> >> >> >>
+> >> >> >> Comments are welcome.
+> >> >> >>
+> >> >> >> BR, YK
+> >> >> >> _______________________________________________
+> >> >> >> Audio/Video Transport Working Group
+> >> >> >> [email-masked]
+> >> >> >> https://www.ietf.org/mailman/listinfo/avt
+> >> >> >
+> >> >
+> >
+> _______________________________________________
+> Audio/Video Transport Working Group
+> [email-masked]
+> https://www.ietf.org/mailman/listinfo/avt
+>
+>

Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
From: Gary Sullivan <[email-masked]>
To: "Even, Roni"@huawei.com, [email-masked]
Date: Mon, 14 Jul 2008 10:48:02 +0200

I think I would have to agree with Roni on that one.

+> -----Original Message-----
+> From: [email-masked] [mailto:[email-masked]] On
+> Behalf Of Even, Roni
+> Sent: Monday, July 14, 2008 1:45 AM
+> To: [email-masked]; [email-masked]
+> Subject: Re: [AVT] spatial-resolution parameter for RFC 3984bis
+>
+> YK,
+> According to H.264 the encoder does not need to scale, this
+> is up to the
+> receiver, so there is no requirement for the sender to support a
+> specific resolution even if it is within the level!!!!
+> Roni
+>
+> > -----Original Message-----
+> > From: [email-masked] [mailto:[email-masked]]
+> > Sent: Monday, July 14, 2008 11:41 AM
+> > To: Even, Roni; [email-masked]
+> > Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> >
+> >
+> > Roni,
+> >
+> > If the requested resolution (100x50) is supported by the Level, and
+> the
+> > offerer agreed or offered the Level, then the offerer MUST
+> accept and
+> > send the resolution. There is no reason that a sender does
+> not support
+> > a
+> > certain resolution complaint to a level the sender supports, right?
+> And
+> > as it is als restricted that the answerer MUST only request a
+> > resolution
+> > complaint to the agreed or offered Level (or any lower
+> Level), it is
+> > then impossible that such a requested resolution cannot be
+> supported
+> by
+> > the offerer.
+> >
+> > If the answerer requests a resolution of a Level that the offerer
+> > cannot
+> > support, the offerer has to reject anyway as it cannot support the
+> > Level
+> > at the first step.
+> >
+> > BR, YK
+> >
+> > >-----Original Message-----
+> > >From: ext Even, Roni [mailto:[email-masked]]
+> > >Sent: 14 July, 2008 10:59
+> > >To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
+> > >Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> > >
+> > >YK,
+> > >Having an upper restriction is OK but you still do not address
+> > >the issue
+> > >of what if the sender can not supply it.
+> > >For example let's say that the request is for a
+> resolution of 100x50,
+> > >what will the sender do if it can not send such
+> resolution, should it
+> > >reject the request, should it send 90x40 or 110x50 if it can?
+> > >Roni
+> > >
+> > >> -----Original Message-----
+> > >> From: [email-masked] [mailto:[email-masked]]
+> > >> Sent: Monday, July 14, 2008 10:55 AM
+> > >> To: Even, Roni; [email-masked]
+> > >> Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> > >>
+> > >>
+> > >> Hi Roni,
+> > >>
+> > >> The resolution must be restricted by the level part of
+> > >profile-level-id
+> > >> and max-fs. Therefore, if a configuration is agreed (or
+> agreeable),
+> > >> then
+> > >> the answerer must request a resolution under the constraint, and
+> the
+> > >> offerer must accept the request as long as it meets the
+> restriction.
+> > >> This is similar as sprop-parameter-sets, as long as it
+> is complaint
+> > >> with
+> > >> the agreed (or agreeable) configuration, the other side
+> must accept
+> > >it.
+> > >>
+> > >> Would it work this way?
+> > >>
+> > >> BR, YK
+> > >>
+> > >> >-----Original Message-----
+> > >> >From: ext Even, Roni [mailto:[email-masked]]
+> > >> >Sent: 14 July, 2008 10:38
+> > >> >To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
+> > >> >Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
+> > >> >
+> > >> >YK,
+> > >> >Just to clarify,
+> > >> >The text on the receiver side says that this is the requested
+> > >> >resolution, it does not address issue of negotiation, what will
+> the
+> > >> >sender do if it cannot send this resolution, should it
+> reject the
+> > >> >stream?.
+> > >> >If this is for negotiation do you except to do a new offer
+> > >> >answer if the
+> > >> >receiver wants a new resolution?
+> > >> >
+> > >> >Roni
+> > >> >
+> > >> >> -----Original Message-----
+> > >> >> From: [email-masked] [mailto:[email-masked]] On
+> > Behalf
+> > >> Of
+> > >> >> [email-masked]
+> > >> >> Sent: Sunday, July 13, 2008 7:57 PM
+> > >> >> To: [email-masked]
+> > >> >> Subject: [AVT] spatial-resolution parameter for RFC 3984bis
+> > >> >>
+> > >> >>
+> > >> >> Concluded from the discussions in the email threads
+> > >listed below, I
+> > >> >> added a new parameter, spatial-resolution, to the RFC
+> > >3984bis draft
+> > >> >> (which will be submitted by tomorrow):
+> > >> >>
+> > >> >>
+> http://www.ietf.org/mail-archive/web/avt/current/msg09425.html
+> > >> >>
+> http://www.ietf.org/mail-archive/web/avt/current/msg09650.html
+> > >> >>
+> > >> >> The parameter is specified as follows (basically as Randell
+> > >> suggested
+> > >> >> in
+> > >> >>
+> http://www.ietf.org/mail-archive/web/avt/current/msg09429.html).
+> > >> >>
+> > >> >> spatial-resolution:
+> > >> >> This parameter MAY be used to indicate the maximum spatial
+> > >> resolution
+> > >> >> of
+> > >> >> a NAL unit stream or the preferred spatial resolution of a
+> > >receiver.
+> > >> >> The value is a base16 [6] (hexadecimal) representation of
+> > >the width
+> > >> >and
+> > >> >> height of the spatial resolution, in pixels, separated by a
+> > comma.
+> > >> >>
+> > >> >> Usage in SDP offer/answer:
+> > >> >> - When "a=sendrecv" or no direction attribute is used,
+> > >> >> "spatial-resolution" indicates both the maximum spatial
+> > resolution
+> > >> of
+> > >> >> the stream sent by the declaring entity and the preferred
+> spatial
+> > >> >> resolution for receiving a stream.
+> > >> >> - When "a=sendonly", "spatial-resolution" indicates
+> the maximum
+> > >> >spatial
+> > >> >> resolution of the outgoing stream.
+> > >> >> - When "a=recvonly", "spatial-resolution" indicates the
+> preferred
+> > >> >> spatial resolution for receiving a stream.
+> > >> >>
+> > >> >> Comments are welcome.
+> > >> >>
+> > >> >> BR, YK
+> > >> >> _______________________________________________
+> > >> >> Audio/Video Transport Working Group
+> > >> >> [email-masked]
+> > >> >> https://www.ietf.org/mailman/listinfo/avt
+> > >> >
+> > >
+> _______________________________________________
+> Audio/Video Transport Working Group
+> [email-masked]
+> https://www.ietf.org/mailman/listinfo/avt
+>
+>