Re: The MediaStream constructor

On 2012-10-16 17:32, Stefan Hakansson LK wrote:
> On 10/09/2012 04:52 PM, Adam Bergkvist wrote:
>> 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.
>
> If I understand correctly, you say that it would make sense to allow
> option 1 (i.e. clone MediaStreams) and 3 (i.e. be able to pick track by
> track).
>
> This makes a lot of sense to me since it is simple to do the simple
> thing (clone MS), but still allows more advanced cases.

This has been silent for a while. Unless anyone objects, I'll update the 
spec with this simpler approach.

/Adam

Received on Monday, 12 November 2012 12:07:22 UTC