- From: Rob Manson <robman@mob-labs.com>
- Date: Tue, 05 Nov 2013 17:22:33 +1100
- To: public-media-capture@w3.org
This thread highlights that we're left with no way to use a post-processed stream/track (e.g. VideoStreamTrack) as a source. Is this really correct? 8( roBman On 5/11/13 4:52 PM, Adam Bergkvist wrote: > 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 06:23:01 UTC