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

["Mo Zanaty (mzanaty)" <[e-mail]>]

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 <[e-mail]> wrote:

Hi Christian,

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

Cheers,
Bo

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] 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,
> 
> 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...."
[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.

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

> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic