W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2012

Re: MediaStream Constructor

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 10 May 2012 00:00:02 -0400
Message-ID: <4FAB3D42.1070001@jesup.org>
To: public-media-capture@w3.org
On 5/9/2012 11:20 PM, Anant Narayanan wrote:
> Hi all,
> We discussed earlier today about the possibility of combining multiple 
> MediaStreams into a single stream via it's constructor; in the context 
> of allowing multiple calls to getUserMedia to obtain a stream for each 
> camera. Even if we don't end up allowing that, it might be useful in 
> other contexts.
> Robert O'Callahan has suggested that we extend the MediaStream 
> constructor to take a list of Objects, which can be a combination of 
> MediaStreams or MediaStreamTracks.
> [Constructor MediaStream(obj1, obj2, obj3, ..., objN)];
> This behavior is much in line with functions like Array.concat [1], 
> and highlights the flexibility JS programmers are accustomed to, since 
> we are not restricted with type safety as much as other languages.
> I haven't mentioned MediaStreamTrackLists though, because I think they 
> are a redundant type that may simply be represented as an array of 
> MediaStreamTracks. If there are good reasons to keep the 
> MediaStreamTrackList around, please do let me know. Otherwise, we can 
> modify the MediaStream object to be:

Well, in theory the arrays of local and remote streams are 'live' 
arrays, and it also was said on the list that they don't compact when 
one is removed (to make them easy to match up with SDP m= lines) - 
though I have to say that MediaStreams don't map well to m= lines if a 
MediaStream as < or > 1 stream of a given type...

We need to have a clear mapping of MediaStreams, MediaStreamTracks, and 
SDP m= lines including for complex cases with tracks and streams being 
added and removed.

Randell Jesup
Received on Thursday, 10 May 2012 04:01:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC