RE: Early Holiday Present: Settings API version 6

> From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
> What does this mean for the concept of remote source types?  Particularly
> Issue no. 5 in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-

> capture/proposals/SettingsAPI_proposal_v6.html#constraint-manipulation-
> api-extensions-to-mediastreamtrack seems to open the door to applying
> constraints to a remote source using mechanisms that as far as I can tell
> are currently undefined.

I think we should work to define them better once v6 is merged. "remote" seems like an interesting and necessary source type, even if we all jointly decide that those sources simply ignore constraints completely...


> Moreover, in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-

> capture/proposals/SettingsAPI_proposal_v6.html#constraint-manipulation-
> api-extensions-to-mediastreamtrack under "Remote Media" it is stated that
> "These requirements for remote media are outside the scope of the Media
> Capture task force".  If we are going to define remote sources and
> possibly how to apply constraints to them, then I don't see how we can cay
> anymore that requirements for remote media are outside the scope of the
> TF.

"Outside the scope of our task force" may be inappropriate wording then. This is meant to convey that we need to work closely with WebRTC to understand and specify how this will work or not. 


> I think that the merged document can still have 'remote' as part of the
> SourceTypeEnum, but any discussion about constraints and their
> applicability to remote sources should be clearly marked as TBD or even
> out-of-scope.

I agree.


> Minor comment:  I still would like to see the definition of 'gain'
> consistent with WebAudio (see https://dvcs.w3.org/hg/audio/raw-

> file/tip/webaudio/specification.html#attributes-GainNode).

They are more-or-less already aligned. From your previous feedback I changed the type from unsigned long to float, and set the initial value at 1. Per my reading of the linked document that's basically the parameter constraints on the WebAudio gain value.


> -----Original Message-----
> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> Sent: Thursday, December 20, 2012 11:10 PM
> To: public-media-capture@w3.org
> Subject: Re: Early Holiday Present: Settings API version 6
> 
> On 12/20/2012 08:33 PM, Travis Leithead wrote:
> > I think this is all great feedback. I'm not going to re-integrate this
> > feedback into the v6 proposal, I'll just expect that this gets
> > clarified in Media Capture and Streams when v6 is adopted in.
> >
> > How's that going by the way?
> 
> In the note sent a couple of days ago, we gave until the end of today (Dec
> 21st) for people to object to starting the integration. There has been no
> objection so far, so I expect the editors are preparing to get started!
> 
> Stefan
> 
> >
> >> -----Original Message----- From: Adam Bergkvist
> >> [mailto:adam.bergkvist@ericsson.com] Sent: Wednesday, December 19,
> >> 2012 12:29 AM To: Martin Thomson Cc: Travis Leithead; Jim Barnett;
> >> public-media-capture@w3.org Subject: Re: Early Holiday Present:
> >> Settings API version 6
> >>
> >> On 2012-12-18 20:12, Martin Thomson wrote:
> >>> I'm inclined to address this differently.  Either:
> >>>
> >>> 1. Provide a "file" device placeholder on all browsers (crappy user
> >>> experience because now we get false positives when apps check to see
> >>> if the user has devices) 2. Create a new device ID for files when
> >>> the user opts to create the file, which to the app appears to be a
> >>> new device that was "plugged in" in response to their request for a
> >>> mic/camera.
> >>>
> >>
> >> I like your idea with a selected file being treated as a device that
> >> gets plugged in as a response to getUserMedia(). It might be quite
> >> common user behavior to plug in new a device when the preferred
> >> webcam doesn't show up in the list of available devices (because it's
> >> in your bag on the floor). With this solution we have the option to
> >> assign this particular file a unique id and let it show up in
> >> getDeviceIds() as a "readonly" source from that point.
> >>
> >> This might satisfy both the cases where you don't want to show some
> >> UI because the user doesn't have any connected devices (Mathew's case
> >> from Lyon), but at the same it lets the user opt in with a file for
> >> privacy reasons and it's gets treated as a newly connected "real"
> >> (readonly) device.
> >>
> >>> I prefer the second, which is very much like your fourth, with one
> >>> difference: getDeviceIds() still works.  Apps can't enumerate files
> >>> (a good thing), but that's OK.  There are several up-sides over what
> >>> you suggest): - apps can't request a specific file - apps can still
> >>> see what "real" devices are present prior to requesting permission
> >>> (necessary for some use cases) - users can choose a file if the app
> >>> permits it, at which point we can decide how much to share with the
> >>> app about that file
> >>>
> >>
> >> The fact that users only can select a file if the app permits it
> >> conflicts with the original idea with files as replacements for
> >> devices for user-empowerment (as Tim nicely describes it in [1]).
> >> I'm not saying that we can't relax that requirement, but we have to
> >> be aware that were doing it.
> >>
> >> /Adam
> >>
> >>> I'm still in two minds as to whether there is one device ID for
> >>> files altogether or whether there is a different device ID for each
> >>> file. I'm leaning toward the former.
> >>>
> >>> I still believe that hiding device IDs until after consent is
> >>> granted is overly cautious.  It prevents some application usage
> >>> scenarios.
> >>
> >> [1]
> >> http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/0018

> >> .html

Received on Friday, 21 December 2012 20:05:10 UTC