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

Re: Constructors and cloning

From: Rob Manson <robman@mob-labs.com>
Date: Tue, 05 Nov 2013 17:22:33 +1100
Message-ID: <52788EA9.9010009@mob-labs.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC