Re: MediaStream Constructor

On 2012-05-10 13:32, 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)]

I like this idea in general. The current approach with separate lists 
for audio and video doesn't really make sense since it's easy to put a 
track in the correct list (i.e. audio or video). Perhaps we could even 
support all three objects as arguments "MediaStream or 
MediaStreamTrackList or MediaStreamTrack".

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

For example, the local operation add() doesn't trigger the addtrack 
event on MediaStreamTrackList according to the spec. That given, local 
operations such as splice and push wouldn't trigger events either. The 
events are meant for external changes to the lists.

I agree with the second point you make about non-standard behaving 
lists. We might need to have such behavior since it's been suggested 
that adding a track to a list will increase the length by one, but 
removing a track will not affect the list length. The removed track will 
simply leave a "whole" in the list to not affect the indexes of the 
other tracks. I think we should keep MediaStreamTrackList, but it needs 
some more work. For example, apart from the special remove behavior, it 
would be convenient to know both how long the list is as well as how 
many tracks it contains (since those numbers may not be equal).

/Adam

> 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 13:58:04 UTC