Subject: [MMUSIC] draft-ietf-mmusic-sdp-simulcast questions

From: Christian Groves <[email-masked]>
Date: Wed, 11 Mar 2015 17:41:15 +1100

Hello,

I've have some questions/comments on draft-ietf-mmusic-sdp-simulcast-00.

Cl.6.1 - "/There are separate and independent sets of parameters for 
simulcast//
//   in send and receive directions.  When listing multiple directions,//
//   each direction MUST NOT occur more than once./"

This doesn't really consider sendrecv. I suggest to modify the first 
sentence to read "There are separate and independent sets of parameters 
for simulcast in send, receive and send & receive direction...."

Cl.6.1 - Indicates that the order of listed simulcast versions in the 
send direction is not significant and the order in the receive direction 
is significant. I assume that the use of "sendrecv" then does infer a 
preference for received streams?

Cl.6.1 - "/Alternative simulcast versions MAY be specified as part of the//
//   attribute parameters by expressing each simulcast version format as a//
//   comma-separated list of alternative values.  In this case, all//
//   combinations of those alternatives MUST be supported./"

I assume the MUST be supported refers to the SDP Offerer, as clause 6.2 
indicates that an Answerer may choose to remove non-desirable 
alternatives. So all combinations including sub-sets must be supported 
by the SDP offerer.

Cl.6.1.2 2nd para - "I/f the offered direction is "sendrecv", the 
answerer MAY keep it , but MAY also change it to "send" or "recv" to 
indicate that it is only interested in simulcast for a single 
direction./" I assume that the answerer may ADD "send" or "recv" in 
addition to maintaining "sendrecv". e.g. where sendrecv has multiple 
versions and the answerer support sendrecv for some versions but send or 
recv for others.

Cl.6.1.2 - I'm confused over the difference in significance of a 
simulcast version vs. a simulcast version alternative in the offer. If 
simulcast versions separated by ";" mean that an offerer will send 
multiple encoded streams (each a simulcast version) for the same source 
at the same time, what is meant by the alternatives separated by ","?

Cl.6.3.1 - Given that the offer contains recv 97 the introduction should 
state that Alice can receive a single video resolution. It should also 
indicate under fig.3 that it can only send a single video in the receive.

Cl.6.1.2 - Where there's a single value in a=simulcast "recv" or "send", 
I guess that means simulcast is not being used in that direction?

Cl.6.3.2 2nd para - What's the significance of "these two simulcast 
versions also have a temporal dependency"? 100 and 101 are linked by 
a=depend for layered encoding. However wouldn't all the simulcast 
versions be temporally (time) related?

Regards, Christian

---

From: Bo Burman <[email-masked]>
Date: Wed, 11 Mar 2015 10:46:21 +0000

Hi Christian,

Thank you for your comments. Please find my responses inline below.

Cheers,
Bo

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: den 11 mars 2015 07:41
> To: mmusic mailing list
> Subject: [MMUSIC] draft-ietf-mmusic-sdp-simulcast questions
> 
> Hello,
> 
> Cl.6.1 - "/There are separate and independent sets of parameters for simulcast//
> This doesn't really consider sendrecv. I suggest to modify the first sentence to read "There are separate and
> independent sets of parameters for simulcast in send, receive and send & receive direction...."
[BoB] OK, this is unintentional since "sendrecv" is part of the defined directions in sc-dir.

> 
> Cl.6.1 - Indicates that the order of listed simulcast versions in the send direction is not significant and the order in the
> receive direction is significant. I assume that the use of "sendrecv" then does infer a preference for received streams?
[BoB] Yes.

> I assume the MUST be supported refers to the SDP Offerer, as clause 6.2 indicates that an Answerer may choose to
> remove non-desirable alternatives. So all combinations including sub-sets must be supported by the SDP offerer.
[BoB] This is related to your question on Cl.6.1.2 below. An "alternative" is a way for the Offerer to express that it can provide a certain simulcast version in one of a set of possible alternative representations. So the Answerer will always keep only a single alternative, per simulcast version that it chooses to use. This will be clarified.

> 
> Cl.6.1.2 2nd para - "I/f the offered direction is "sendrecv", the answerer MAY keep it , but MAY also change it to "send" or
> "recv" to indicate that it is only interested in simulcast for a single direction./" I assume that the answerer may ADD
> "send" or "recv" in addition to maintaining "sendrecv". e.g. where sendrecv has multiple versions and the answerer
> support sendrecv for some versions but send or recv for others.
[BoB] Yes, as long as the answer expresses a restriction and not an extension compared to what is offered. Will add some clarifying text.

> 
> Cl.6.1.2 - I'm confused over the difference in significance of a simulcast version vs. a simulcast version alternative in the
> offer. If simulcast versions separated by ";" mean that an offerer will send multiple encoded streams (each a simulcast
> version) for the same source at the same time, what is meant by the alternatives separated by ","?
[BoB] As said above, an "alternative" is a way for the offerer to express that it can provide a certain simulcast version in one of a set of possible alternative representations. For example, offering three video simulcast versions (three simultaneous streams with different encoded formats), where the first version can be provided in either SHVC or SVC alternatives, the second version can be provided in either SVC, H264 or VP8 alternatives, and the third version can be provided in either H264 or VP8 alternatives. If that was not already clear, I think the text in 6.1 must be improved in that aspect, better explaining exactly what an "alternative" is in this context.

> 
> Cl.6.3.1 - Given that the offer contains recv 97 the introduction should state that Alice can receive a single video
> resolution.
[BoB] That is "normal" SDP, and nothing specific for simulcast. I however think that we could point out (even earlier in the text, like in 6.1) that the proposed solution explicitly indicates also which streams that are _not_ simulcast (by including a single simulcast version). Do you want to highlight the presence of this non-simulcast stream?

> It should also indicate under fig.3 that it can only send a single video in the receive.
[BoB] Do you mean you would like to highlight that there is also a single version (non-simulcast stream) in the answer, corresponding to the one in the offer, but with reversed direction?

> 
> Cl.6.1.2 - Where there's a single value in a=simulcast "recv" or "send", I guess that means simulcast is not being used in
> that direction?
[BoB] Yes, as hopefully made clear above.

> 
> Cl.6.3.2 2nd para - What's the significance of "these two simulcast versions also have a temporal dependency"? 100 and
> 101 are linked by a=depend for layered encoding. However wouldn't all the simulcast versions be temporally (time)
> related?
[BoB] Yes, all simulcast versions are temporally related, but in general not time _dependent_ on one another. The text is supposed to highlight that simulcast streams, besides being  related through simulcast, may also, optionally, have a Layered Multi-Stream relationship (section 3.7 in draft-ietf-avtext-rtp-grouping-taxonomy). This means that the Received Dependent Stream simulcast version cannot be reconstructed into a Received Source Stream without the Received Encoded Stream simulcast version it is dependent on. This temporal dependency is only used as an example of Layered Multi-Stream co-existence with simulcast.

> 
> Regards, Christian
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 11 Mar 2015 15:19:49 +0000

After discussing with Bo, we may need better terminology or more
clarifying text for ³simulcast versions² and "alternatives².

A simulcast version is an RTP Stream from a common Media Source in
-taxonomy [1]. Multiple simulcast versions means multiple concurrent RTP
Streams from a common Media Source. For example, HD and thumbnail
simulcast versions sent concurrently as separate RTP Streams.

Alternatives within a simulcast version serve the same purpose as
alternative PTs in non-simulcast SDP, to allow multiple media formats for
a given RTP Stream, in the sense of dynamic switching not concurrent
transmission. There is no corresponding term in -taxonomy. For an example
of alternatives, if all conference participants can decode H.264 and
H.265, but only some can encode H.265, both H.264 and H.265 can be listed
as alternatives, and the format may dynamically switch between H.264 and
H.265 as different participants become active speaker.

One further clarification inline below.

Mo

[1] https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy

On 3/11/15, 6:46 AM, Bo Burman <[email-masked]> wrote:

Hi Christian,

Cheers,
Bo

>sentence to read "There are separate and
[BoB] OK, this is unintentional since "sendrecv" is part of the defined
directions in sc-dir.

>send direction is not significant and the order in the
> receive direction is significant. I assume that the use of "sendrecv"
>then does infer a preference for received streams?
[BoB] Yes.

>indicates that an Answerer may choose to
> remove non-desirable alternatives. So all combinations including
>sub-sets must be supported by the SDP offerer.
[BoB] This is related to your question on Cl.6.1.2 below. An "alternative"
is a way for the Offerer to express that it can provide a certain
simulcast version in one of a set of possible alternative representations.
So the Answerer will always keep only a single alternative, per simulcast
version that it chooses to use. This will be clarified.
[Mo] The answer may keep multiple alternatives per simulcast version, just
like non-simulcast cases using current SDP O/A rules.

>answerer MAY keep it , but MAY also change it to "send" or
> "recv" to indicate that it is only interested in simulcast for a single
>direction./" I assume that the answerer may ADD
> "send" or "recv" in addition to maintaining "sendrecv". e.g. where
>sendrecv has multiple versions and the answerer
[BoB] Yes, as long as the answer expresses a restriction and not an
extension compared to what is offered. Will add some clarifying text.

>simulcast version vs. a simulcast version alternative in the
> offer. If simulcast versions separated by ";" mean that an offerer will
>send multiple encoded streams (each a simulcast
[BoB] As said above, an "alternative" is a way for the offerer to express
that it can provide a certain simulcast version in one of a set of
possible alternative representations. For example, offering three video
simulcast versions (three simultaneous streams with different encoded
formats), where the first version can be provided in either SHVC or SVC
alternatives, the second version can be provided in either SVC, H264 or
VP8 alternatives, and the third version can be provided in either H264 or
VP8 alternatives. If that was not already clear, I think the text in 6.1
must be improved in that aspect, better explaining exactly what an
"alternative" is in this context.

>state that Alice can receive a single video
> resolution.
[BoB] That is "normal" SDP, and nothing specific for simulcast. I however
think that we could point out (even earlier in the text, like in 6.1) that
the proposed solution explicitly indicates also which streams that are
_not_ simulcast (by including a single simulcast version). Do you want to
highlight the presence of this non-simulcast stream?

> It should also indicate under fig.3 that it can only send a single video
[BoB] Do you mean you would like to highlight that there is also a single
version (non-simulcast stream) in the answer, corresponding to the one in
the offer, but with reversed direction?

>versions also have a temporal dependency"? 100 and
> 101 are linked by a=depend for layered encoding. However wouldn't all
>the simulcast versions be temporally (time)
> related?
[BoB] Yes, all simulcast versions are temporally related, but in general
not time _dependent_ on one another. The text is supposed to highlight
that simulcast streams, besides being  related through simulcast, may
also, optionally, have a Layered Multi-Stream relationship (section 3.7 in
draft-ietf-avtext-rtp-grouping-taxonomy). This means that the Received
Dependent Stream simulcast version cannot be reconstructed into a Received
Source Stream without the Received Encoded Stream simulcast version it is
dependent on. This temporal dependency is only used as an example of
Layered Multi-Stream co-existence with simulcast.

---

From: Christian Groves <[email-masked]>
Date: Thu, 12 Mar 2015 13:42:00 +1100

Hello Bo and Mo,

Thanks for the replies, please see my responses below.

Regards, Christian

> clarifying text for ³simulcast versions² and "alternatives².
[CNG] I think so. I was going to raise the issue of terminology but I 
wanted to see the response to my questions.
> simulcast versions sent concurrently as separate RTP Streams.
[CNG] I think this is better text because is introduces the concept of 
concurrency.
> H.265 as different participants become active speaker.
[CNG] Again I find this text better because it addresses the aspect of 
dynamic switching. This didn't really seem to be addressed by the draft.
>> ..snip..
[CNG] The responses get to the heart of my confusion. It isn't clear 
from the current text how the alternatives would be reduced and what 
"MUST" be supported meant in this context. From Mo's description and my 
understanding of how I thought it would work was that the Offer would 
contain a set of alternates which indicates that the Offerer must 
support each alternative for the simulcast version. The answerer may 
then reduce the set of alternates. The offerer may then use any of the 
alternates from this set in the simulcast version but only one 
alternative at a time.
> extension compared to what is offered. Will add some clarifying text.
[CNG] Yes, it would be a restriction to what is offered.
> "alternative" is in this context.
[CNG] I think the aspect that was missing was the aspect of concurrency 
and switching that Mo alludes about the definitions and how this relates 
to alternative and simulcast version.
> highlight the presence of this non-simulcast stream?
[CNG] I would have thought that as it is part of new SDP i.e. 
a=simulcast that you would describe what the recv part meant in the example.
> the offer, but with reversed direction?
[CNG] To be complete, I was more thinking about extending the text 
"...The included format parameters indicates that sent simulcast 
versions can differ in video resolution and framerate. <It also 
indicates that simulcast is not used in the receive direction.>"
> Layered Multi-Stream co-existence with simulcast.
[CNG] OK. I wouldn't have thought that "temporal" would be the right 
term but I'm not a video coding expert.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 12 Mar 2015 03:30:58 +0000

We will clarify this text to indicate the offerer MUST support all offered
format alternatives of each simulcast version. The confusion likely comes
from ³In this case, all combinations of those alternatives MUST be
supported². An earlier proposal had ways to express specific combinations
of alternatives and versions, but this was rejected as overly complex
(capneg territory). For example, HD and thumbnail versions, with VP8 or
H.264 alternatives, but restricted to the same codec for both versions,
i.e. allow HD H.264 with thumbnail H.264, allow HD VP8 with thumbnail VP8,
but disallow the combination of HD H.264 with thumbnail VP8. The current
draft allows all combinations of alternatives and versions without further
restrictions.

Cheers,
Mo

On 3/11/15, 10:42 PM, Christian Groves <[email-masked]>
wrote: