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

["Charles Eckel (eckelcu)" <[e-mail]>]

I think we are all in agreement that for a large conference (e.g. 100+ audio/video streams), we cannot require that each media stream have its own m=section, nor can we require that each media stream's SSRC is signaled in SDP. For the sake of example, let's assume a centralized conference server is able to send up to 10 video streams, where each video stream may be any of the 100 video streams at various points in time (e.g. active speakers switched in/out, specific sources requested, etc.), I think there are three realistic alternatives:

1) Use 10 m=sections to define the ten video streams, no multiplexing required
2) Use 1 m=section to define  a video stream, and indicate that up to 10 video streams are multiplexed within it
3) Use 'n' m=sections to define the video streams, where 1<=n<=10

We already have all we need to do (1). There is a desire to improve on (1).
If we define some additional syntax/semantics that enable (2), people can choose to use (2) or (3) depending on works best for their scenario. There have already been some drafts submitted along these lines, I suggest to take a closer look at those and improve on them. Sounds reasonable?

Charles

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Adam Roach
> Sent: Tuesday, February 05, 2013 10:26 AM
> To: Justin Uberti
> Cc: [e-mail]
> Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single
> m= line
> 
> On 2/4/13 02:45, Justin Uberti wrote:
> 
> 
> 	Sorry for the short lead time, but here's a quick read for the plane.
> 
> 
> I addressed several of the assertions made in this draft in my previous
> response (e.g. the need for glare resolution regardless of which solution we
> select). Some additional thoughts:
> 
> 
> 
> 	   o  Adding or removing a source requires sending a full list of all
> 	      sources, which doesn't scale well to 10s or 100s of sources,
> 	      especially when they are added or removed frequently.
> 
> 
> Realistically, this isn't how multiparty conferences are handled. It's
> unrealistic to think that my DSL connection is going to be sucking down
> hundreds of video streams just because I'm in a video conference with
> hundreds of people.
> 
> In practice, the way existing conferencing systems handle this is to send a
> small, manageable number of streams to each participant, changing them
> out as necessary to have a reasonable user experience (either under the
> control of the user, its own algorithms, or a combination of the two).
> 
> Which is to say: even with hundreds of source streams being fed into a
> conference system, you're really looking at a realistic upper bound on m=
> sections of a dozen or two, simply because you can't reasonably expect
> recipients to receive more than that many streams simultaneously.
> 
> And really, if you're imagining hundreds of media streams flowing towards
> an endpoint, any arguments about the bits consumed by SDP go well
> beyond disingenuous.
> 
> 
> 
> 	   o  Because this solution requires BUNDLE, which is still not widely
> 	      supported, it can be deployed in fewer situations
> 
> 
> This is completely out of left field: the alternative is MMT, which is even
> less well developed than BUNDLE.
> 
> 
> 
> 	   4.  The RFC5576-based approach has already been in use for many
> years
> 	       in a major video conferencing system (Google+ Hangouts), and
> has
> 	       worked very well.  We feel that we have searched the
> "unknown"
> 	       space and solved all of the major issues.
> 
> 
> I think this actually does a good job of illustrating your blind spot: you're
> working within RTCWEB, but developing for a single, very precise use case.
> For example, this kind of experience doesn't translate well into the
> challenges that might arise from systems that are dealing with radically
> different user experiences. Google-hangout-type uses are certainly
> important, but they're not the only thing we're designing for. You need to
> think about systems with pre-encoded (stored) media; systems with radical
> imbalances in the processing power and device capabilities between the
> endpoints; systems with different stream control models, etc, etc.
> 
> 
> 
> 	       On the other hand, the multi m=
> 	       section approach has never been tried by anyone, that we are
> 	       aware of
> 
> 
> Do a web search for "Marconi ViPr."
> 
> /a