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

RE: Constructors and cloning

From: Mandyam, Giridhar <mandyam@quicinc.com>
Date: Mon, 4 Nov 2013 20:28:24 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <CAC8DBE4E9704C41BCB290C2F3CC921A1664016F@nasanexd01h.na.qualcomm.com>
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.  

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.  

-Giri

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Monday, November 04, 2013 11:03 AM
To: public-media-capture@w3.org
Subject: Re: Constructors and cloning

My alternate suggestion is to remove the constructor for MediaStreamTrack until we have a good story on how we want to use naked tracks; at the moment, no such compelling story has been told, as far as I can tell, so I'd want to call that a "post version 1" feature.

I would also suggest that AudioStreamTrack and VideoStreamTrack be removed from the spec, since they now have no visible properties.

Replacing MediaStream.clone() with a MediaStream(MediaStream) constructor doesn't matter to me - the difference seems to be syntax, not semantics.

On 11/04/2013 10:51 AM, Adam Bergkvist wrote:
> Hi
>
> In the current spec, we have the following APIs to create new 
> instances of MediaStream and MediaStreamTrack:
>
> ------------
> MediaStream() constructor
>  - sequence<MediaStreamTrack>
>  - MediaStream (used to clone the given stream, but behavior changed
> (accidentally?) when we switched to explicit cloning of tracks)
>
> MediaStream.clone()
>
> AudioStreamTrack() constructor
>  - Constraints
>
> VideoStreamTrack() constructor
>  - Constraints
>
> MediaStreamTrack.clone()
> ------------
>
> I belive the API surface we expose for this functionality is a whole 
> lot bigger than it would have to be. The Audio/VideoStreamTrack 
> interfaces are empty now when getSourceIds() have become getDevices() 
> on Navigator. I think we could get away with something like below:
>
> ------------
> MediaStream() constructor
>  - sequence<MediaStreamTrack> (add specified tracks to new stream)
>  - MediaStream (clone given stream; including tracks)
>
> MediaStreamTrack() constructor
>  - kind, Constraints (replaces constructors on derived types)
>  - MediaStreamTrack (clone given track)
> ------------
>
> /Adam
>


--
Surveillance is pervasive. Go Dark.
Received on Monday, 4 November 2013 20:28:53 UTC

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