Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 01 Dec 2009 15:21:04 +0200

Resending, as the messages was hold due to too many recipients. The hold
message was cancelled. 

  _____  

From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 3:00 PM
To: 'Mo Zanaty (mzanaty)'; 'Roni Even'; 'Stuart Taylor (sttaylor)';
[email-masked]'
Cc: 'Cullen Jennings (fluffy)'; [email-masked]';
[email-masked]'; [email-masked]'; 'Chelliah Sivachelvan
(chelliah)'; [email-masked]'
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

The following text in subsection 8.2.2 clearly tells that level downgrade is
different from level asymmetry, as Randell and Roni explained. If you don't
want level asymmetry, you just don't include the parameter or let the value
be equal to 0, then you can freely choose to do level downgrade or not. In
conclusion, I don't see any problem with the current text. 
 
o          The parameter "level-asymmetry-allowed" indicates whether level
asymmetry is allowed.

If "level-asymmetry-allowed" is equal to 0 (or not present) in either the
offer or the answer, level asymmetry is not allowed.  In this case, the
level to use in the direction from the offerer to the answerer MUST be the
same as the level to use in the opposite direction, and the common level to
use is equal to the lower value of the default level in the offer and the
default level in the answer.

Otherwise ("level-asymmetry-allowed" equals to 1 in both the offer and the
answer), level asymmetry is allowed.  In this case, the level to use in the
offerer-to-answerer direction MUST be equal to the highest level the
answerer supports for receiving, and the level to use in the
answerer-to-offerer direction MUST be equal to the highest level the offerer
supports for receiving.

When level asymmetry is not allowed, level upgrade is not allowed, i.e. the
default level in the answer MUST be equal to or lower than the default level
in the offer.

BR, YK

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo
Zanaty (mzanaty)
Sent: Tuesday, December 01, 2009 4:10 AM
To: Roni Even; Stuart Taylor (sttaylor); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

I think the confusion might be due to the following text in section 8.1. It
is ambiguous whether "level asymmetry" refers to the actual RTP media level
or the SDP offer/answer level. I assume the RTP media level was intended.
But if some readers interpret this as the SDP offer/answer level, they will
incorrectly conclude that this parameter is required in order to use a
different level in the SDP answer even for level downgrade.

       level-asymmetry-allowed:
          This parameter MAY be used in SDP Offer/Answer to indicate
          whether level asymmetry, i.e., using a different level in the
          offerer-to-answerer direction than the level in the answerer-
          to-offerer direction, is allowed.  The value MAY be equal to
          either 0 or 1.  When the parameter is not present, the value
          MUST be inferred to be equal to 0.  The value 1 in both the
          offer and the answer indicates that level asymmetry is
          allowed.  The value of 0 in either the offer or the answer
          indicates the level asymmetry is not allowed.
 
          If "level-asymmetry-allowed" is equal to 0 (or not present)
          in either the offer or the answer, level asymmetry is not
          allowed.  In this case, the level to use in the direction
          from the offerer to the answerer MUST be the same as the
          level to use in the opposite direction.

Mo Zanaty

  _____  

From: Roni Even [mailto:[email-masked]] 
Sent: Monday, November 30, 2009 6:40 PM
To: Mo Zanaty (mzanaty); Stuart Taylor (sttaylor); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

Hi,

I think that it is clear since it addresses asymmetry and not the downgrade
of the level.

Asymmetry means not the same level in both directions.

Roni

From: Mo Zanaty (mzanaty) [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 12:51 AM
To: Stuart Taylor (sttaylor); Roni Even; [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

This inconsistency in the original RFC 3984 was pointed out several times
before on this list, and was one of the key things to clarify in 3984 bis. I
think the current draft is clear in this regard, except for the description
of level-asymmetry-allowed, which might be clearer if it explicitly
mentioned that level downgrade is always allowed regardless of this
parameter.

Mo Zanaty

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart
Taylor (sttaylor)
Sent: Monday, November 30, 2009 4:56 PM
To: Roni Even; [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

Current usage is justified by the following paragraph, later in section
8.2.2 of RFC-3984, which admittedly can be interpreted multiple ways:

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

Stuart Taylor

From: Roni Even [mailto:[email-masked]] 
Sent: Monday, November 30, 2009 4:50 PM
To: Stuart Taylor (sttaylor); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]; [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

Hi,

Just to remind all of you that the current text in RFC3984 mandated level
symmetry - downgrading was not allowed - see section 8.2.2 of RFC3984

" The parameters identifying a media format configuration for H.264

      are "profile-level-id", "packetization-mode", and, if required by

      "packetization-mode", "sprop-deint-buf-req".  These three

      parameters MUST be used symmetrically; i.e., the answerer MUST

      either maintain all configuration parameters or remove the media

      format (payload type) completely, if one or more of the parameter

      values are not supported."

This means that every shipping product that does level downgrade is not
compliant, and therefore cannot claim that the current text break backward
computability.

The 3984bis draft is addressing the issue and the current text and products
should align to it.  If the text is not clear enough than it should be fixed
but the backward computability should address the issue that some
implementations did support the standard and supported only symmetry as
discussed in  RFC3984

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart
Taylor (sttaylor)
Sent: Monday, November 30, 2009 10:19 PM
To: [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]; [email-masked]
Subject: [AVT] Comment on 3984bis: level-asymmetry-required

I am commenting on H.264 level asymmetry in general and the
level-asymmetry-allowed attribute, introduced in draft 8 of RFC-3984bis, in
particular.  The current draft contains  confusing language and is likely to
break compatibility with many existing devices.

The current language implies that level-asymmetry-allowed applies to both
downgrading and upgrading the level in an answer.  In its absence neither is
therefore allowed.  However, it is only in the description of
level-asymmetry-allowed that this is indicated.  The first paragraphs of
Section 8.2.2 explicitly state that level downgrading is allowed, without
mention of the level-asymmetry-allowed attribute until later.  There are
four examples of level asymmetry given:  level-asymmetry-allowed is absent
in the three downgrade cases and present only the one upgrade case.   Thus
it might be reasonable to infer an intent that level-asymmetry-allowed only
applies to upgrades.

More seriously, I am concerned that this attribute changes the SDP semantics
in a way that is not backwards compatible.  There is a statement near the
end of RFC-3984 Section 8.2.2 which is commonly interpreted as meaning the
level can be downgraded:

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

All the H.264 SIP devices that I am familiar with allow the level to be
downgraded in an answer, and some depend on it.  As an example, the
Radvision 3545 MCU will answer any H.264 offer with Level 1.2 (or less, when
operating in "standard rate" mode), and then depend on the remote end to
conform.  All current Cisco endpoints (and Cisco Unified Communications
Manager, acting as B2BUA for SCCP and H.323 devices) use this
interpretation.  If the lack of level-asymmetry-allowed means an endpoint
cannot answer with a lower level, the installed base of these devices will
be non-conformant when 3984bis goes into effect.

Not having been privy to the discussions leading up to this, I do not
understand why level-asymmetry-allowed is required.  Downgrading is an
important mechanism for negotiation between different level endpoints.
Upgrading is harmless in any case: an endpoint is always allowed to encode
at a lower level than negotiated.  If an offering endpoint doesn't like the
answer it can always re-INVITE without the offending PT.

>From my perspective, any of the following are acceptable:

1.       Drop the level-asymmetry-allowed parameter entirely and
unconditionally permit level asymmetry in SDP negotiation.

2.       Change the default to "level-asymmetry-allowed=1", meaning that
legacy endpoints get permissive treatment.

3.       Reverse "level-asymmetry-allowed" to "level-asymmetry-required"
(and leave the default as off).

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Tue, 1 Dec 2009 09:56:33 -0600

It's clear if you go into with the right understanding of level
asymmetry.  Since we have a whole group here at Cisco who were confused,
I suggest we need some more clarity.

The confusion stems from the clause, "... level asymmetry, i.e., using a
different level in the offerer-to-answerer direction than the level in
the answerer-to-offerer direction, is allowed."  The problem is
establishing the context: is this referring to the negotiation or
sending media?  I suggest the following change in section 8.1:

level-asymmetry-allowed:

This parameter MAY be used in a SDP offer/answer to indicate whether
level asymmetry, i.e., sending media encoded at a different level in the
offerer-to-answerer direction than the level in the answerer-to-offerer
direction, is allowed.  The value MAY be equal to 0 or 1.  [...]

Stuart

Hi,

I think that it is clear since it addresses asymmetry and not the
downgrade of the level.

Roni

This inconsistency in the original RFC 3984 was pointed out several
times before on this list, and was one of the key things to clarify in
3984 bis. I think the current draft is clear in this regard, except for
the description of level-asymmetry-allowed, which might be clearer if it
explicitly mentioned that level downgrade is always allowed regardless
of this parameter.

Mo Zanaty

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stuart Taylor (sttaylor)

*         Parameters declaring a configuration point are not
downgradable,

Stuart Taylor

Hi,

Just to remind all of you that the current text in RFC3984 mandated
level symmetry - downgrading was not allowed - see section 8.2.2 of
RFC3984

This means that every shipping product that does level downgrade is not
compliant, and therefore cannot claim that the current text break
backward computability.

The 3984bis draft is addressing the issue and the current text and
products should align to it.  If the text is not clear enough than it
should be fixed but the backward computability should address the issue
that some implementations did support the standard and supported only
symmetry as discussed in  RFC3984

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stuart Taylor (sttaylor)

I am commenting on H.264 level asymmetry in general and the
level-asymmetry-allowed attribute, introduced in draft 8 of RFC-3984bis,
in particular.  The current draft contains  confusing language and is
likely to break compatibility with many existing devices.

The current language implies that level-asymmetry-allowed applies to
both downgrading and upgrading the level in an answer.  In its absence
neither is therefore allowed.  However, it is only in the description of
level-asymmetry-allowed that this is indicated.  The first paragraphs of
Section 8.2.2 explicitly state that level downgrading is allowed,
without mention of the level-asymmetry-allowed attribute until later.
There are four examples of level asymmetry given:
level-asymmetry-allowed is absent in the three downgrade cases and
present only the one upgrade case.   Thus it might be reasonable to
infer an intent that level-asymmetry-allowed only applies to upgrades.

More seriously, I am concerned that this attribute changes the SDP
semantics in a way that is not backwards compatible.  There is a
statement near the end of RFC-3984 Section 8.2.2 which is commonly
interpreted as meaning the level can be downgraded:

*         Parameters declaring a configuration point are not
downgradable,

All the H.264 SIP devices that I am familiar with allow the level to be
downgraded in an answer, and some depend on it.  As an example, the
Radvision 3545 MCU will answer any H.264 offer with Level 1.2 (or less,
when operating in "standard rate" mode), and then depend on the remote
end to conform.  All current Cisco endpoints (and Cisco Unified
Communications Manager, acting as B2BUA for SCCP and H.323 devices) use
this interpretation.  If the lack of level-asymmetry-allowed means an
endpoint cannot answer with a lower level, the installed base of these
devices will be non-conformant when 3984bis goes into effect.

Not having been privy to the discussions leading up to this, I do not
understand why level-asymmetry-allowed is required.  Downgrading is an
important mechanism for negotiation between different level endpoints.
Upgrading is harmless in any case: an endpoint is always allowed to
encode at a lower level than negotiated.  If an offering endpoint
doesn't like the answer it can always re-INVITE without the offending
PT.

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 01 Dec 2009 19:04:38 +0200

OK, we will add something like this, once we get the chance to edit the
draft before the RFC is published.
 
BR, YK

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart
Taylor (sttaylor)
Sent: Tuesday, December 01, 2009 5:57 PM
To: Roni Even; Mo Zanaty (mzanaty); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

It's clear if you go into with the right understanding of level asymmetry.
Since we have a whole group here at Cisco who were confused, I suggest we
need some more clarity.

The confusion stems from the clause, ". level asymmetry, i.e., using a
different level in the offerer-to-answerer direction than the level in the
answerer-to-offerer direction, is allowed."  The problem is establishing the
context: is this referring to the negotiation or sending media?  I suggest
the following change in section 8.1:

level-asymmetry-allowed:

This parameter MAY be used in a SDP offer/answer to indicate whether level
asymmetry, i.e., sending media encoded at a different level in the
offerer-to-answerer direction than the level in the answerer-to-offerer
direction, is allowed.  The value MAY be equal to 0 or 1.  [.]

Stuart

Hi,

Roni

Mo Zanaty

  _____  

.         Parameters declaring a configuration point are not downgradable,

Stuart Taylor

Hi,

Roni Even

.         Parameters declaring a configuration point are not downgradable,

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 1 Dec 2009 11:07:54 -0800

One additional point of clarification is that if
level-asymmetry-allowed=0 or is not specified, the SDP answer is
restricted to the same or lower levels than that in the SDP offer AND
the level in the answer is symmetric.
If level-asymmetry-allowed=1, the answer may include a higher level AND
the level is asymmetric.

I think this dual functionality:
a) allowing level increase in SDP
b) allowing different level in one direction than the other

contributes to the confusion. Clarifying this in the description of
level-asymmetry-allowed would be helpful.

Cheers,
Charles

> -----Original Message-----
Ye-Kui Wang
> Sent: Tuesday, December 01, 2009 9:05 AM
> OK, we will add something like this, once we get the chance to edit
the draft before the RFC is
> published.
> 	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stuart Taylor (sttaylor)
> 	Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked];
> [email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]
> 	It's clear if you go into with the right understanding of level
asymmetry.  Since we have a
> whole group here at Cisco who were confused, I suggest we need some
more clarity.
> 
> 
> 
> 	The confusion stems from the clause, "... level asymmetry, i.e.,
using a different level in the
> offerer-to-answerer direction than the level in the
answerer-to-offerer direction, is allowed."  The
> problem is establishing the context: is this referring to the
negotiation or sending media?  I suggest
> 	This parameter MAY be used in a SDP offer/answer to indicate
whether level asymmetry, i.e.,
> sending media encoded at a different level in the offerer-to-answerer
direction than the level in the
> answerer-to-offerer direction, is allowed.  The value MAY be equal to
0 or 1.  [...]
> 	Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked];
> [email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]
> 	I think that it is clear since it addresses asymmetry and not
the downgrade of the level.
> 	Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked];
> [email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]
> 	This inconsistency in the original RFC 3984 was pointed out
several times before on this list,
> and was one of the key things to clarify in 3984 bis. I think the
current draft is clear in this
> regard, except for the description of level-asymmetry-allowed, which
might be clearer if it explicitly
parameter.
> 	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stuart Taylor (sttaylor)
> 	Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked];
> [email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]
> 	Current usage is justified by the following paragraph, later in
section 8.2.2 of RFC-3984, which
> admittedly can be interpreted multiple ways:
> 
> 
> 
downgradable,
> 	Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; Chelliah
> Sivachelvan (chelliah); [email-masked]; [email-masked]
> 	Just to remind all of you that the current text in RFC3984
mandated level symmetry - downgrading
> was not allowed - see section 8.2.2 of RFC3984
> 
> 
> 
> 	This means that every shipping product that does level downgrade
is not compliant, and therefore
> cannot claim that the current text break backward computability.
> 
> 
> 
> 	The 3984bis draft is addressing the issue and the current text
and products should align to it.
> If the text is not clear enough than it should be fixed but the
backward computability should address
> the issue that some implementations did support the standard and
supported only symmetry as discussed
> in  RFC3984
> 
> 
> 
> 	Roni Even
> 
> 
> 
> 	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stuart Taylor (sttaylor)
> 	Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; Chelliah
> Sivachelvan (chelliah); [email-masked]; [email-masked]
level-asymmetry-allowed attribute,
> introduced in draft 8 of RFC-3984bis, in particular.  The current
draft contains  confusing language
> and is likely to break compatibility with many existing devices.
> 
> 
> 
> 	The current language implies that level-asymmetry-allowed
applies to both downgrading and
> upgrading the level in an answer.  In its absence neither is therefore
allowed.  However, it is only
> in the description of level-asymmetry-allowed that this is indicated.
The first paragraphs of Section
> 8.2.2 explicitly state that level downgrading is allowed, without
mention of the level-asymmetry-
> allowed attribute until later.  There are four examples of level
asymmetry given:  level-asymmetry-
> allowed is absent in the three downgrade cases and present only the
one upgrade case.   Thus it might
> be reasonable to infer an intent that level-asymmetry-allowed only
applies to upgrades.
> 
> 
> 
> 	More seriously, I am concerned that this attribute changes the
SDP semantics in a way that is
> not backwards compatible.  There is a statement near the end of
RFC-3984 Section 8.2.2 which is
> commonly interpreted as meaning the level can be downgraded:
> 
> 
> 
downgradable,
> 	All the H.264 SIP devices that I am familiar with allow the
level to be downgraded in an answer,
> and some depend on it.  As an example, the Radvision 3545 MCU will
answer any H.264 offer with Level
> 1.2 (or less, when operating in "standard rate" mode), and then depend
on the remote end to conform.
> All current Cisco endpoints (and Cisco Unified Communications Manager,
acting as B2BUA for SCCP and
> H.323 devices) use this interpretation.  If the lack of
level-asymmetry-allowed means an endpoint
> cannot answer with a lower level, the installed base of these devices
will be non-conformant when
> 3984bis goes into effect.
> 
> 
> 
> 	Not having been privy to the discussions leading up to this, I
do not understand why level-
> asymmetry-allowed is required.  Downgrading is an important mechanism
for negotiation between
> different level endpoints.  Upgrading is harmless in any case: an
endpoint is always allowed to encode
> at a lower level than negotiated.  If an offering endpoint doesn't
like the answer it can always re-
> INVITE without the offending PT.
> 
> 
> 
unconditionally permit level
> asymmetry in SDP negotiation.
> 
> 	2.       Change the default to "level-asymmetry-allowed=1",
meaning that legacy endpoints get
> permissive treatment.
> 
> 	3.       Reverse "level-asymmetry-allowed" to
"level-asymmetry-required" (and leave the default
> as off).

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 02 Dec 2009 12:27:38 +0200

OK, I will also try to improve the clarity herein once we get the chance to
edit the draft before the RFC is published.

BR, YK 

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: Tuesday, December 01, 2009 9:08 PM
> To: Ye-Kui Wang; Stuart Taylor (sttaylor); [email-masked]
> Importance: Low
> level-asymmetry-allowed=0 or is not specified, the SDP answer 
> is restricted to the same or lower levels than that in the 
> SDP offer AND the level in the answer is symmetric.
> If level-asymmetry-allowed=1, the answer may include a higher 
> level AND the level is asymmetric.
> 
> contributes to the confusion. Clarifying this in the 
> description of level-asymmetry-allowed would be helpful.
> 
> Cheers,
> Charles
> 
> Behalf Of

---

From: "Vikram Khurana (vkhurana)" <[email-masked]>
Date: Wed, 2 Dec 2009 09:06:51 -0800

Hi YK,

   We have been having this discussion on the side here among ourselves
at Cisco.
   Is the following list of operation-points in an Offer valid :
   a=fmtp:97 profile-level-id=53000c; packetization-mode=1;
      sprop-operation-point-info=<1,level=1.3,320x180>,
                                 <4,level=1.3, CIF>
                                 <7,level=1.3, QVGA>
                                 <5,level=3.0, 4CIF>
                                 <2,level=3.1,640x360>,
                                 <6,level=3.1, 1408x1152>
                                 <3,level=3.2,1280x720>;
                                 <8,Level 3.2,VGA>

   When I read the text of 3984bis, it does not clearly state if such a
case would be invalid.
   Here I am thinking of a conferencing bridge, which is capable of
supporting
   varying and markedly different resolutions and frame rates, which may
not fit in a single hierarchy.
   The text refers to "lowest operation point" and "highest operation
point".
   What do they mean.. highest.. is it the one with all the layers of
the most complex layering configuration
   supported ? Then the above offer seems valid. Or are all operation
points limited to a single hierarchy ?
   That sounds simpler but limits the scope IMO.

Regards,
-vikram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ye-Kui Wang
Sent: Wednesday, December 02, 2009 2:28 AM
To: Charles Eckel (eckelcu); Stuart Taylor (sttaylor); [email-masked]
Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

OK, I will also try to improve the clarity herein once we get the chance
to
edit the draft before the RFC is published.

BR, YK 

> "level-asymmetry-required" (and leave the default

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Vikram Khurana (vkhurana)" <[email-masked]>
Date: Wed, 2 Dec 2009 09:12:22 -0800

I meant SVC draft.. Not 3984bis. Sorry.

-vikram

-----Original Message-----
From: Vikram Khurana (vkhurana) 
Sent: Wednesday, December 02, 2009 9:07 AM
To: 'Ye-Kui Wang'; Charles Eckel (eckelcu); Stuart Taylor (sttaylor);
[email-masked]

Hi YK,

Regards,
-vikram

-----Original Message-----

BR, YK

---

From: "Vikram Khurana (vkhurana)" <[email-masked]>
Date: Fri, 4 Dec 2009 08:44:21 -0800

Hi YK,

   When I read the text of SVC draft, it does not clearly state if such
a case would be invalid.

Regards,
-vikram

---

From: Roni Even <[email-masked]>
Date: Fri, 04 Dec 2009 19:58:59 +0200

Hi,
I think that the syntax you gave is not according with the definition. Each
description must have 10 elements, some of them must have values and some
can be empty. Reading the text it seems to me that if you use the right
syntax you can specify the list you gave. The operation points must be
ordered from lower to higher.

Roni Even

> Vikram Khurana (vkhurana)
> Sent: Friday, December 04, 2009 6:44 PM
> To: Ye-Kui Wang; [email-masked]
> Subject: [AVT] Comment on 3984bis: Meaning of Highest/Lowest Operation
> Point
> 
> 
> Hi YK,
>

---

From: "Vikram Khurana (vkhurana)" <[email-masked]>
Date: Fri, 4 Dec 2009 10:12:48 -0800

Thanks for clarifying that Roni.

   Yes, the operation-point syntax does have 10 parameters.
   But, when we talk of higher or lower operation point, I assume we
referring to them by their profile-level, Right ?
   The 10 parameters are:
   1: layer-ID 
   2: temporal-ID
   3: dependency-ID 
   4: quality-ID 
   5: profile-level-ID 
   6: avg-framerate
   7: width
   8: height
   9: avg-bitrate
   10:max-bitrate

Regards,
vikram

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Friday, December 04, 2009 9:59 AM
To: Vikram Khurana (vkhurana); 'Ye-Kui Wang'; [email-masked]
Subject: RE: [AVT] Comment on 3984bis: Meaning of Highest/Lowest
Operation Point

Hi,
I think that the syntax you gave is not according with the definition.
Each
description must have 10 elements, some of them must have values and
some
can be empty. Reading the text it seems to me that if you use the right
syntax you can specify the list you gave. The operation points must be
ordered from lower to higher.

Roni Even

---

From: Roni Even <[email-masked]>
Date: Sat, 05 Dec 2009 00:39:20 +0200

Hi,
This is a good question since you can have the same level with different
width and height, the level just provides a maximum of macro blocks but not
specific geometry (CIF, QCIF). So I assume that in your case the temporal
information may be the same for all layers so in this case the order will be
by the dependency_id 

Just note that you may run into geometry distortion if the you try to
combine layers from different sources without considering the pixel aspect
ratio.

BTW: there is also some MMUSIC drafts for allowing the receiver to ask for
geometry in http://tools.ietf.org/html/draft-ietf-mmusic-image-attributes-03
which references RFC5583. The sprop parameter allows the sender to provide
information about the layers he intends to send but does not allow the
receiver to ask for specific resolutions. 

Roni Even

> From: Vikram Khurana (vkhurana) [mailto:[email-masked]]
> Sent: Friday, December 04, 2009 8:13 PM
> To: Roni Even; Ye-Kui Wang; [email-masked]

---

From: Thomas Schierl <[email-masked]>
Date: Sat, 05 Dec 2009 08:31:10 +0100

Dear Vikram,

Actually, the title of this email seems to be misreading, since it 
addressed the SVC draft and not 3984bis.

You may misinterpret the text in the SVC draft. Operation point 
definitions by "operation-point-info" are maid for a single and valid 
SVC stream containing multiple layers, where the lowest operation point 
declares the first one in decoding order of the stream. Your example 
seems to be wrong, since the order of the operations points should 
follow the decoding order. Operation point info does not give a bunch of 
possible encodings, it does give a detailed description of the SVC 
stream intended to be sent by the offerer. And the answerer selects up 
to which operation point it wants to receive the SVC stream including 
all lower layers using the parameter scalable-layer-id.

Best regards,
Thomas

-- 
Thomas Schierl
--------------
Fraunhofer HHI

---

From: "Vikram Khurana (vkhurana)" <[email-masked]>
Date: Mon, 7 Dec 2009 13:26:23 -0800

Hi,

   Thanks Roni for your clarifications. 
   I would still want the spec to clearly specify what a higher or lower
operation point is.

   I think the order should be based on Profile-Level only and they can
be in any order
   within the same profile-level.  It's essentially the nature of
application which 
   defines what is more important, resolution, frame rate, etc. Spec
should not limit that.

   Please share your thoughts on it.

Regards
-vikram

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Friday, December 04, 2009 2:39 PM
To: Vikram Khurana (vkhurana); 'Ye-Kui Wang'; [email-masked]
Subject: RE: [AVT] Comment on 3984bis: Meaning of Highest/Lowest
Operation Point

Hi,
This is a good question since you can have the same level with different
width and height, the level just provides a maximum of macro blocks but
not
specific geometry (CIF, QCIF). So I assume that in your case the
temporal
information may be the same for all layers so in this case the order
will be
by the dependency_id 

Just note that you may run into geometry distortion if the you try to
combine layers from different sources without considering the pixel
aspect
ratio.

BTW: there is also some MMUSIC drafts for allowing the receiver to ask
for
geometry in
http://tools.ietf.org/html/draft-ietf-mmusic-image-attributes-03
which references RFC5583. The sprop parameter allows the sender to
provide
information about the layers he intends to send but does not allow the
receiver to ask for specific resolutions. 

Roni Even