- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 5 Nov 2013 06:52:49 +0100
- To: "Mandyam, Giridhar" <mandyam@quicinc.com>, Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-11-04 21:28, Mandyam, Giridhar wrote: > As per the terminology definition of a MediaStreamTrack source > (http://dev.w3.org/2011/webrtc/editor/getusermedia.html#terminology), > "A source can be a physical webcam, microphone, local video or audio > file from the user's hard drive, network resource, or static image." > I thought that the MediaStreamTrack constructor would be useful in > creating tracks corresponding to sources outside of webcams and > microphones. But I have not seen an example yet about how this is > supposed to work, and I don't know how it would be done myself. > Threrefore, I don't disagree with getting rid of the MediaStreamTrack > constructor either. If we have a MediaStreamTrack(MediaStreamTrack) constructor for cloning tracks we can always overload it later to introduce new ways of creating a track. > The current version of the ImageCapture specification leverages > VideoStreamTrack in the constructor. In the absence of > VideoStreamTrack, a MediaStreamTrack could also be used in the > constructor but a MediaStreamTrack.kind check must be performed. That would work. VideoStreamTrack and AudioStreamTrack have been in the spec for a while, but we haven't added anything more to them; on the contrary, we have removed stuff. So a single MediaStreamTrack type where you can check the kind of the media seem to work for us. /Adam
Received on Tuesday, 5 November 2013 05:53:13 UTC