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

Re: The MediaStream constructor

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 9 Oct 2012 16:52:34 +0200
Message-ID: <50743A32.7050805@ericsson.com>
To: "Tommy Widenflycht (ᛏᚮᛘᛘᚤ)" <tommyw@google.com>
CC: Anant Narayanan <anant@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2012-10-08 11:32, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
> Ping on this. Implementation details aside no other API takes a
> mix-n-match of different objects. An ordinary JS array with Tracks or a
> MediaStreamtrackList is still my strong preference.

Looking at from usage point of view. I think the most common use case 
would be to clone a stream.

var clonedStream = new MediaStream(stream);

If we optimize for that case we get:

Idl: [Constructor (MediaStream stream)]

An alternative to that is to also allow a list streams to combine streams:

var clonedStream = new MediaStream(stream);
var cobinedStream = new MediaStream([stream1, stream2])

Idl: [Constructor ((MediaStream or MediaStream[]) streams)]

WebSocket does this for its protocols argument.


A case that's not as common but very powerful is to pick single tracks 
from any source:

// create a stream with specific tracks for a recording
var audioStream = new  MediaStream([
         stream1.audioTracks[0],
         stream2.audioTracks[0]
]);

To support that we need:
Idl: [Constructor (MediaStreamTrack[] tracks)]


My guess is that people will mostly use streams and tracks since those 
are the objects that they interact with regularly. But that just 
speculation from my side.

/Adam
Received on Tuesday, 9 October 2012 14:53:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:02 GMT