Re: MediaStream Constructor

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.

I agree. One other context could be for the mixing of e.g. pre-recorded 
audio/video content with live camera data in to a single MediaStream object.

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

It would probably be better to allow MediaStream and 
MediaStreamTrackList objects, where a MediaStreamTrackList object can 
contain one or more MediaStreamTrack objects. I've given some 
explanation on why I think we should keep MediaStreamTrackList below.

>
> [Constructor MediaStream(obj1, obj2, obj3, ..., objN)];

This does limit the potential to extend the MediaStream constructor with 
additional arguments later on (e.g. options). We should probably keep 
that possibility open and instead specify the MediaStream constructor as 
follows (which is also in line with the new Blob object constructor 
proposal [1]):

[Constructor, Constructor((MediaStream or MediaStreamTrackList)?[] streams)]

As a developer you could then do any of the following:

var stream = new MediaStream();

var stream = new MediaStream([mediaStram1, mediaTrackList1, ..., objN]);

This also means that at some later point in time we could adopt an 
options argument if or when we might need that:

[Constructor, Constructor((MediaStream or MediaStreamTrackList)?[] 
streams, optional MediaStreamProperties options)]

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

IIUC, firing onaddtrack and onremovetrack when objects are added 
directly to an array object means we'll have to add special behavior to 
standard Array handling. We would need to intercept any method calls to 
e.g. splice, slice, push, etc on Arrays objects...but only when they are 
called on an Array living in a MediaStream object.

With MediaStreamTrackList as a live collection object we know to fire 
events when user's call an explicit method (i.e. 'add'/'remove' 
methods). Other parts of the web platform also use Collection objects 
rather than Array objects if any non-standard behavior is to be attached 
to an attribute.

We could certainly tighten up the definition of the MediaStreamTrackList 
collection interface and I would be happy to take an action to propose 
some text here.

>
> I support these two changes proposed above. Feedback appreciated!
>
> Regards,
> -Anant

[1] http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob

Received on Thursday, 10 May 2012 11:32:49 UTC