Re: MediaStream Constructor

On 2012-05-10 15:57, Adam Bergkvist wrote:
> 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
s/whole/hole/
> 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 14:03:57 UTC