Subject: Re: [AVT] SST switched multipoint conferences

From: Thomas Schierl <[email-masked]>
Date: Mon, 11 Jan 2010 10:56:52 +0100

Dear Stuart,

Please find our reply inline.

Best regards,
Thomas

Am 22.12.2009 15:40, schrieb Stuart Taylor (sttaylor):
 > Authors,
 >
 > Thank you for your consideration.  Your response indicates that you
 > intended to create a framework for the type of negotiation we need.
 > However, the current draft fails to state some important assumptions,
 > which permits multiple interpretations.
 >
 > If I understand your answers correctly, you assume that when an offerer
 > declares sprop-operation-point-info it is declaring not only what it
 > wants to send, but also what it wants to receive. This goes a long way
 > to satisfying our requirements, but I do not see where this assumption
 > is stated in the draft.  The concept of layering plan symmetry, where
 > both endpoints send using the same layering structure, is not discussed.
 >
 > Based on that assumption, I have some questions:
 >
 > Question 1:
 > If an answerer uses profile-level-id instead of scalable-layer-id, is it
 > still obligated to use the offered layering plan when sending?
 >

Because of its priority and backward compatibility, the use of a 
different profile-level-id would overwrite the profile and level as 
offered in the operation-point-info. Anyhow, if the answered profile and 
level are still high enough to satisfy the layering scheme up to a 
certain layer-id, why should the layering scheme not work? A smart SVC 
receiver would be able to do a reasonable decision using the offered 
information. As stated in earlier emails, the capability of the 
receiver/sender is limited by the profile and level to decode/encode 
only! Aspect ratios or resolutions are part of an additional mechanism, 
which could be the image attributes in Ingemar's draft.

 > Question 2:
 > Is either endpoint allowed to change its sending layering plan to be
 > inconsistent with the declared sprop parameters without a re-INVITE?
 >

It can accept by replying with "scalable-layer-id" or as mentioned 
before with just "profile-levle-id", otherwise it would have to do a 
re-invite, which AFAIK is a typical procedure in such scenarios.

 > Question 3:
 > If an answer contains sprop-operation-point-info, is it allowed to be
 > inconsistent with the offered sprop-operation-point-info?  If yes, does
 > that mean asymmetric layering plans are supported under the draft?
 >

See my answer above + if you do want to negotiate asymmetric layering 
schemes, you would have to use send-only and receive-only attributes 
plus potential re-invites.

 > Question 4:
 > We are confused the sentence, "A receiver MAY indicate its choice of the
 > highest layer it wants to send and/or receive using the optional media
 > type parameter scalable-layer-id."  Note that the sentence should start
 > with "An answerer" instead of "A receiver", since both endpoints can be
 > receivers and only the answerer can use scalable-layer-id (right?), but
 > that's not the problem.  Which of the following interpretations are
 > true?
 >

You are right, this sentence needs to be corrected as proposed above.

 > A)  The answerer will receive all the layers with a lower layer_id
 > value, even if there is no dependency between the selected layer and the
 > lower-numbered layer.
 >
 > B)  The answerer will receive all the layers that are required to
 > compose the selected operation point, implying that layers independent
 > of the selected operation point (even with a lower layer_id) will not be
 > sent.
 >

The answerer will receive all layers which are indicated in the 
sprop-operation-point-info and which are required for decoding up to the 
selected scalable-layer-id. From a codec point of view, all  layers with 
lower DTQ-triple values are required for a consistent SVC bit-stream. 
However, a smart sender will leave out the transmission of NAL units 
unused for reference. Here, I do not mean NAL units of higher temporal 
levels of lower Dependency-IDs as stated in your option C).

 > C)  The answerer will receive all the layers that are required to
 > compose the selected operation point and all the operation points that
 > precede the selected operation point in the sprop-operation-point-info
 > (regardless of layer_id value).  If this is the answer, what does it
 > mean if only sprop-scalablity-info, and not sprop-operation-point-info,
 > is declared?
 >
 > Note that the layering plan is not unidimensional: temporal layers to
 > construct CIFp30 may precede layers to construct 4CIFp15. An endpoint
 > may not want to receive 30 fps layers after selecting 4CIFp15.  However,
 > a conference bridge will want to receive all the layers required to
 > construct both.
 >
 > Question 5:
 > How would level-asymmetry-allowed be applied when
 > sprop-operation-point-info and scalable-layer-id are employed?  I would
 > like it to permit the sprop-operation-point-info to declare layers that
 > exceed the default profile-level-id, implying they may be sent but
 > cannot be received.  Similarly, the scalable-layer-id answer should not
 > limit the layers (within the plan) that the answerer can send.
 >

I do not understand, why the offers in operation-point-info should 
exceed the profile and level declared in profile-level-id. Remember, if 
you want to have asymmetry, you can separately negotiate the sent and 
received streams. And, I guess its up to the client to make smart 
decisions, depending on the received offer.

Overall, we do not really understand, why there is a need for an 
additional parameter to differentiate between operation points to be 
sent and to be received. Offer/answer allows for this differentiation 
using the send-only and receive-only attributes. Why should we put 
something additional into the SVC draft? If there is a reason to improve 
O/A, why not to propose a generic solution for it?

 >
 > Best regards,
 > Stuart Taylor
 >
 >
 > -----Original Message-----
 > From: Ye-Kui Wang [mailto:[email-masked]]
 > Sent: Friday, December 18, 2009 8:00 AM
 > To: Stuart Taylor (sttaylor); 'Ingemar Johansson S';[email-masked]
 > Cc:[email-masked]; 'Stephan Wenger'; 'Thomas Schierl'; 'Alex
 > Eleftheriadis'
 > Subject: RE: [AVT] SST switched multipoint conferences
 >
 >
 >
 > Hi Stuart,
 >
 > We have studied and discussed your inputs among us authors of the draft,
 > and
 > here are our comments. Our comments are directly responding to your
 > minimum
 > requirements. This way, all your proposed text changes are hopefully
 > covered.
 >
 > 1. The declared operation points are explicitly required to conform to
 > a single consistent layering scheme with an unambiguous hierarchy.  This
 > is
 > implied by the current draft but not actually stated.
 >
 > [Authors] We think that this is clear in the current draft. Once an SDP
 > includes sprop-operation-point-info, the layer structure is clearly
 > indicated
 > without ambiguity. However, we can certainly improve the clarity if you
 > point out the specific places where it is required.
 >
 > 2. By answering an SVC offer containing sprop-operation-point-info, the
 > answerer is agreeing to the declared operation points (up to the
 > layer-id
 > specified in the answer) for both receiving and sending.  The answerer's
 > encoder must produce a stream that is compatible with, but not
 > necessarily
 > identical to, the negotiated operation points.
 >
 > [Authors]: We think that this is also clear. If the direction attribute
 > is
 > sendrecv or not present, then what is said in the SDP applies to both
 > sending and receiving. If direction attribute of sendonly is present,
 > what
 > is said in the SDP applies to only sending. If direction attribute of
 > recvonly is present, what is said in the SDP applies to only receiving.
 >
 > We propose that either the sprop-operation-point-info is always used
 > symmetrically or that the offer should indicate whether symmetry is
 > required
 > through a new attribute.
 >
 > [Authors]: We don't understand the logic between this proposal and the
 > above
 > requirement. Could you please clarify if the direction attribute is not
 > sufficient.
 >
 > 3. We suggest the following syntax for an indication that
 > sprop-operation-point-info should be interpreted symmetrically:
 > recv-operation-points=<comma separated list of layer id numbers>.  This
 > allows the offering endpoint to indicate the properties of important
 > layer
 > combinations, presumably matching the capabilities of various
 > represented
 > endpoints.  The identified layers correspond to identifiers in the
 > sprop-operation-point-info declared in the same offer, ordered by
 > priority.
 >
 > [Authors]: Once the answerer chooses one operation point, the server
 > will
 > send all the lower layers required for presenting the operation point.
 > In
 > addition, layer IDs themselves are naturally in priority order. These
 > are
 > clear from the definitions of "layer", "operation points" etc. from
 > section
 > 3. Therefore, we don't see the need of this proposed change.
 >
 > 4. When sprop-operation-point-info declares an operation point with
 > layer-id=1, this is describing the SVC base layer.  In the multipoint
 > use
 > case described here we should expect the conference bridge to always
 > declare
 > this layer, but there may be other use cases where this is not true.  If
 > declared, all parties must produce a stream that can be shaped down an
 > AVC
 > stream which is consistent with this base layer definition.  The
 > profile-level-id is interpreted as in RFC-3984bis.  For AVC
 > interoperability, parameters of this layer other than the
 > profile-level-id
 > are to be taken as strong hints rather than mandates.
 >
 > [Authors]: A conforming SVC bitstream must contain an AVC base layer. It
 > is
 > not possible to have a conforming SVC bitstream without an AVC base
 > layer.
 > The profile-level-id is specified in this SVC draft. Of course, the
 > semantics for the AVC base layer are the same as that described in
 > 3984bis.
 > Therefore, we don't see the need of a change to address this
 > requirement.
 >
 > 5. The answering endpoint is not required to exactly match the layering
 > scheme used by the offering endpoint.  A stream is compatible with the
 > negotiated operation points if one of the following is true:
 > a. It contains only a base layer that is compliant with the
 > profile-level-id defined in the operation point identified as layer-id
 > #1.
 > Compliance is defined as in RFC-3984, implying that the encoder may
 > produce
 > at a lower level than indicated by the profile-level-id.
 >
 > [Authors]: Encoders are always allowed to output a bitstream that is
 > actually of a lower level than the one declared. We don't see the need
 > for a
 >
 > change herein.
 >
 > b. It contains a base layer that is complaint with the declared base
 > layer in all particulars, optionally plus enhancement layers.  The
 > aggregate
 > of all layers should match at least one of the negotiated operation
 > points
 > by having the same frame dimensions, frame rate and maximum bit rate
 > less
 > than or equal to that operation point, and consistent with to the
 > profile-level-id.
 >
 > [Authors]: When the chosen operation point includes more than the base
 > layer, the
 > bitstream of the chosen operation point must certainly match what is
 > chosen.
 > And again, encoders are always allowed to output a bitstream that is
 > actually of a lower level than the one declared. Therefore, we think
 > that
 > this
 > requirement is already met by the current draft.
 >
 > Best Regards,
 > Authors of the SVC draft
 >
 >
 >
 >
 >

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Mon, 11 Jan 2010 11:02:12 -0600

Thomas,

Thank you again for your responses.  However, I think we are talking
to cross purposes.  While I have several issues with the current draft,
There is one central one that needs to be resolved first: the authors
are apparently assuming that the layering plan will be used 
symmetrically by offerer and answerer.  However, I see nothing in 
the draft which states that this SHOULD or MUST be the case.

As written, sprop-operation-point-info (as with all the other sprop
parameters) declares the intended sending behavior of the offerer.
It's clear that the answering endpoint MAY use the same plan when
sending, but I see no indication that is it obligated to do so.
If there was simply a statement that the same layering plan SHOULD
or MUST be used by both the offerer and answerer when sending, we
would have a basis for further discussion.

If I am simply missing where this statement is made, then I apologize
for wasting your time.

Best Regards,
Stuart

-----Original Message-----
From: Thomas Schierl [mailto:[email-masked]] 
Sent: Monday, January 11, 2010 4:57 AM
To: Stuart Taylor (sttaylor)
Cc: Ye-Kui Wang; Ingemar Johansson S; [email-masked];
[email-masked]; Stephan Wenger; Alex Eleftheriadis
Subject: Re: [AVT] SST switched multipoint conferences

Dear Stuart,

Best regards,
Thomas