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

 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. 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


----

Your comment on A. Examples This section is non-normative. The following
e...:
> http://www.w3.org/TR/2012/WD-html-media-capture-20120712/#examples
> 
> I like the example of camera access; I think that makes usage clear to 
> developers.
> 
> I would like also like to see an example of microphone access, and an 
> example of camcorder+audio input.


Working Group Resolution (LC-2638):
Added examples of a video and audio capture to specification, see
http://dev.w3.org/2009/dap/camera/#examples

----

Received on Tuesday, 11 September 2012 20:15:02 UTC