Re: [MMUSIC] Simulcast: Inclusion of the same SCID in multiple Simulcast streams

["Roni Even" <[e-mail]>]

Hi Magnus,
I would like to verify that I understand this correctly.

The case is about having a media source that sends simulcast streams in two
RTP sessions represented in SDP by two m-lines. The first one will have, for
example, HD resolution and CIF while the second will have SD and same CIF as
the first one. You suggest to not allow having the CIF in both RTP sessions
but still allow having, for example, one with HD and VGA and a second with
SD and CIF?

I see value when using multicast with simulcast to have one multicast group
with HD and a second multicast with SD and maybe a third multicast with CIF
from the same source (example case is streaming live events (sports, ...)
using simulcast and multicast for distribution)

Roni

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Magnus
> Westerlund
> Sent: Tuesday, November 01, 2016 11:46 AM
> To: mmusic (E-mail); [e-mail]
> Subject: [MMUSIC] Simulcast: Inclusion of the same SCID in multiple
> Simulcast streams
> 
> WG,
> 
> During the reviews of the edits yesterday I did find one more issue that
> should be resolved to avoid interoperability issues. There is currently no
text
> making it explicit if it is allowed to have the same simulcast format (and
thus
> SCID) appear in multiple simulcast streams. I believe that unless we
either
> explicit allow this or explicitly disallow it implementations will make
different
> interpretations and thus we end up with interoperability issues.
> 
> So the reason Bo and I didn't conclude yesterday that this is a bad idea
and
> we should just explicitly disallow it because it would simplify things are
two
> reasons.
> 
> The first is that as we have attempted to create the best possibilities
for
> future extensions, e.g. for multicast or at least spread one media source
over
> multiple RTP sessions. Thus, forbidding things can cause issues for the
ones
> defining such extensions, unless we see it necessary to ensure the base
> mechanism working.
> 
> Secondly, there are actually usage benefits for allowing a format to be
> included in multiple simulcast streams. A not unusual way to consider
> simulcast streams is that they fulfill a purpose in the application. For
example
> one simulcast is the video suitable to present the current speaker in a
better
> fidelity version with higher resolution. One may also have a simulcast
stream
> suitable for the recent speakers that is an intermediate format between
high
> resolution and low resolution thumbnails. In such a case the simulcast
stream
> for the high resolution could include a least preferred simulcast format
> (SCID=Y) of a rather low resolution version (for being the high
resolution) as
> the last fallback for this streams purpose. At the same time the
intermediate
> simulcast stream could include the same format SCID=Y as suitable format
> for this medium resolution usage, possible with a much higher preference
as
> it would provide good quality for this streams purpose. So by including
the
> same format in two streams, in situation where the media sender becomes
> resource restrained, for example in bandwidth, the media source sender
> could make the decision that the best way of providing both the high and
> intermediate simulcast streams are to select to send a single RTP stream
> according to SCID=Y that matches both.
> 
> If one would not allow an SCID to be in multiple simulcast streams, then
the
> likely result in the above case is that one have to turn of the high
resolution
> simulcast stream due to insufficient resources. This may or may not mean
> that the application logic chooses to use the intermediate stream as stand
in
> for the high, given that the stream fits the restriction of any of the
high
> resolution simulcast stream's formats.
> 
> So, this example is not particular convincing in regards to why one should
> allow this, as the application logic and with some care when negotiating
the
> simulcast formats for the different streams still can allow a simulcast
using
> middlebox to utilize the simulcast stream as stand in for another
simulcast
> stream if that one is not available.
> 
> So, I currently don't have any better example of why one would allow it,
but I
> think it is important that the WG gets to think about this. So please
consider
> if you have usage that would benefit from allowing multiple simulcast
> streams to include the same format (with the same SCID)? If no good usage
> arises then I suggest we explicitly disallow it.
> Please provide your feedback by the end of the IETF meeting (18th of
> November).
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic