- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 16 Oct 2012 17:32:50 +0200
- To: public-media-capture@w3.org
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. Stefan > > /Adam > > >
Received on Tuesday, 16 October 2012 15:33:16 UTC