Subject: [clue] Fwd: [MMUSIC] More thoughts on multiple media streams in a single m= line

From: Mary Barnes <[email-masked]>
Date: Sun, 17 Feb 2013 12:45:24 -0600

Another relevant discussion for CLUE.

---------- Forwarded message ----------
From: Bernard Aboba <[email-masked]>
Date: Sat, Feb 16, 2013 at 2:53 PM
Subject: Re: [MMUSIC] More thoughts on multiple media streams in a
single m= line
To: Magnus Westerlund <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

Comments below.

> I definitely want to comment on this from an RTP usage perspective that
> might be very relevant to remember. Even with a centralized conference
> solution there is two very distinct solutions in RTP how to transmit a
> session where you have total of 100 participants and you receive 5 video
> streams.
>
> A) Central point with conceptual sources
> In this case the central entity creates conceptual RTP streams that
> carries all the media intended for a specific usage, for example main
> video, thumbnail one, thumbnail two, thumbnail three, thumbnail four.
>
> B) Central point doing source projection
> In this case there exist 100 potential RTP streams and SSRC from the
> central point down to the receiver. However, at any point no more than
> five will actually have RTP packets. But as activity changes and which
> is most relevant for the receiver the SSRCs in use will switch.
>
> For a solution where each SSRC requires its own m= line A) is definitely
> preferable as it will not require renegotiating the properties for these
> five conceptual streams. However, B will require a large number of m=
> lines and dynamic updates as participants comes and go.

[BA] I think there are advantages to A even if multiple SSRCs are
declared within a m-line.  If the "main" video and "thumbnails" change
SSRCs, even with multiple SSRCs on an m-line, you'd still need to
renegotiate unless SVC is being used, right?

> If one had a single m= line per RTP session and media type, the amount

> of updates/renegotiation depends on the amount of meta data about
> streams that you have put in the SDP. The solutions A) and B) can be

> identical from an SDP perspective.

[BA] That's not obvious to me. Even if you have a single m=line per
RTP session and media type,
you can still have individual a=ssrc lines within a m= line.  In case
B, as participants come and go,
aren't dynamic updates still required?  Also, instead of many m=lines,
you'll have many a=ssrc
lines.

> The above two cases I am quite certain we did discuss in the CLUE
> interim meeting in Stockholm when discussing topologies and also the
> relationship between RTP streams (SSRC) and their origin, i.e. media
> source/capture.

[BA] Were there any specific requirements that arose in the CLUE
discussion?  In general, given some of the context issues, it would be
helpful to understand whether we're engineering a solution for RTCWEB
use cases, CLUE use cases, or both.

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