RE: Early Holiday Present: Settings API version 6

Hi Cullen,

> As just one example, I will encourage people that have worked with video white balance to check out the white balance setting.

Don't think Travis is to blame for that one - I proposed it in Camera Settings, see http://gmandyam.github.com/media-capture/#whitebalancemodeenum.  This is consistent with what our drivers currently support in our chipset, and with native API's such as Android (see http://developer.android.com/reference/android/hardware/Camera.Parameters.html).  But is your concern more about SW implementations of such features when they aren't available natively?

> seem to go against many of the decisions we already made about constraints

Can you be more specific?  I think this is consistent with what has been discussed for the past 6 months.

-Giri

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@iii.ca] 
Sent: Monday, December 24, 2012 6:04 AM
To: Stefan Hakansson LK
Cc: public-media-capture@w3.org
Subject: Re: Early Holiday Present: Settings API version 6


I just read this draft now 

1) it looks problematic in many ways - glad to discuss next time we have some face to face time. Many of the things seem a) very hard to implement in a browser b) way overly constrained and hard to extent in the future c) not lined up with how existing software process video. As just one example, I will encourage people that have worked with video white balance to check out the white balance setting. 

2) seem to go against many of the decisions we already made about constraints. 

I strongly object to putting it in the editor draft. I also talked to someone at mozilla and it seemed like they had not been following it. I think we need agreement to put this is in - right now what I misty see is very few people are following it. 


PS - sorry this is from my IETF email address but my Cisco email seems down for holidays ....


On Dec 21, 2012, at 12:10 AM, Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> wrote:

> 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/001
>>> 8.html
>

Received on Monday, 24 December 2012 23:04:32 UTC