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

Re: The MediaStream constructor

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 13 Nov 2012 09:52:22 +0100
Message-ID: <50A20A46.4050701@alvestrand.no>
To: public-media-capture@w3.org
On 11/12/2012 01:06 PM, Adam Bergkvist wrote:
> 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
>
>
Sounds good to me. Please do.
Received on Tuesday, 13 November 2012 08:51:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:12 UTC