Re: MediaStream Constructor

Rich Tibbett wrote:
> 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)]

Also, does it make more sense to specify the constructor on the 
LocalMediaStream interface instead of on the much more generic 
MediaStream interface?

Then, does it make sense to also only allow LocalMediaStream objects to 
be passed in the constructor so we're explicitly disallowing remote 
streams to be mixed with local media stream? I'm fairly sure we don't 
want remote media streams mixed with local media streams in a single 
MediaStream object but others may have use cases where that makes sense.

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

s/user's/users/ ;)

s/to an attribute/to an array-like 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:45:39 UTC