Re: [media-capture][LC] HTML Media Capture Comments ( LC-2637 LC-2638)

Hi, Audio WG-

On 9/11/12 10:15 PM, frederick.hirsch@nokia.com wrote:
>   Dear Doug Schepers ,
>
> The Device APIs Working Group has reviewed the comments you sent [1] on the
> Last Call Working Draft [2] of the HTML Media Capture published on 12 Jul
> 2012. Thank you for having taken the time to review the document and to
> send us comments!
>
> The Working Group's response to your comment is included below.
>
> Please review it carefully and let us know by email at
> public-device-apis@w3.org if you agree with it or not before 18 September
> 2012.

(1 week for comment responses doesn't seem adequate.)

> In case of disagreement, you are requested to provide a specific
> solution for or a path to a consensus with the Working Group. If such a
> consensus cannot be achieved, you will be given the opportunity to raise a
> formal objection which will then be reviewed by the Director during the
> transition of this document to the next stage in the W3C Recommendation
> Track.
>
> Thanks,
>
> For the Device APIs Working Group,
> Dave Raggett
> Dominique Hazaël-Massieux
> W3C Staff Contacts
>
>   1. http://www.w3.org/mid/4FFF382B.70204@w3.org
>   2. http://www.w3.org/TR/2012/WD-html-media-capture-20120712/
>
>
> =====
>
> Your comment on 5.1 Attributes capture of type DOMString:
>> == Video and Audio ==
>> http://www.w3.org/TR/2012/WD-html-media-capture-20120712/#attributes
>>
>> The 'camcorder' keyword value may conflate video and audio; I can
>> credibly see a use-case for video-only capture, and user expectation may
>>
>> be ambiguous if that's not called out explicitly when they are selecting
>>
>> their input (e.g. they may be unpleasantly surprised when they accept a
>>
>> video source and their audio is also captured).
>>
>> The user may also wish to select a different microphone input than is
>> bundled with the videocamera.
>>
>> I suggest that the value of @capture should be a list of strings, not
>> just a single value, i.e.
>>    <input type="file" accept="image/*" capture="camcorder,microphone">
>>
>> This may result in a pair of source selections, sequentially selecting
>> first the videocamera input, then the microphone input (or, depending on
>>
>> the UA and device, might have both in the same dialog... either way, it
>>
>> should be explicit).
>
>
> Working Group Resolution (LC-2637):
> No change needed:
>
> The accept attribute takes precedence over the capture attribute as per the
> spec. This means camcorder+audio would be the same as no capture attribute
> is present if the implementation's video camera control is unable to
> capture audio only. If the implementation's video camera control is able to
> capture audio only (in addition to video), then camcorder+audio and
> microphone+audio would yield similar results i.e. an audio file.
>
> http://lists.w3.org/Archives/Public/public-device-apis/2012Aug/0101.html

Sorry, I'm not satisfied by this response.

It ignores the central point I was making because of a flaw in my 
strawman syntax. I'll restate.


The user may wish to select a different audio and video sources, for a 
variety of reasons, for example:
* the videocamera might not have a microphone
* the user may have a much better microphone than the one available with 
the videocamera
* the user may wish to accept an audio input, or a video input, but not 
both, even if both are requested (for instance, I don't typically turn 
on my camera for skype calls, even if the other person has... but I may 
want to for specific calls); privacy shouldn't rely on local muting or 
blanking... it should be implicit in the request.

You shouldn't assume that the videocamera source explicitly includes 
audio, or that the author wants to capture both video and audio (they 
may want just video, for privacy reasons), or that the user should 
assume that audio is included in any video request (again, for privacy 
reasons).

Here is an improved example of what separate capture values might look 
like, with appropriate accept values:

<input type="file"
        accept="video/*, audio/*"
        capture="camcorder,microphone">

Regards-
-Doug

Received on Wednesday, 12 September 2012 04:57:13 UTC