[html-media-capture] DAP HTML Media Capture update, resolution of LC-2637 on audio/video capture attribute values?

Doug

Thanks for attending the DAP F2F and discussing the Last Call comments on "HTML Media Capture".

We have updated the editors draft to reflect that discussion, including a rewrite of the abstract and introduction - this should clarify the role of "HTML Media Capture" and its relationship to "Media Capture and Streams".

The changed sections read ( http://dev.w3.org/2009/dap/camera/ ):

[[

Abstract

The HTML Media Capture specification defines HTML form extensions that facilitate user access to media capture capabilities of the hosting device. These form extensions enable the upload of still images, video, and audio directly from a device capture mechanism but capture the default offered by the device, providing limited control over what is captured. More detailed control, including management of related streams, is provided by the Media Capture and Streams specification [GETUSERMEDIA<http://dev.w3.org/2009/dap/camera/#bib-GETUSERMEDIA>].

1. Introduction

This section is non-normative.

The HTML Media Capture specification enables web page authors to declaratively specify the upload of audio, video and still images by adding a new attribute to the HTMLinput element. This enables unified capture and upload from the device capture device without requiring a user to save a file and then upload it in separate steps.

Such an approach does not provide detailed user control over capture, so use cases requiring correlating specific individual audio and video streams may be met by using another specification, Media Capture and Streams [GETUSERMEDIA<http://dev.w3.org/2009/dap/camera/#bib-GETUSERMEDIA>]. Access to media streams from the hosting device is out of scope for this specification.

This specification extends the HTMLInputElement<http://dev.w3.org/2009/dap/camera/#dfn-htmlinputelement> interface with a new capture<http://dev.w3.org/2009/dap/camera/#dfn-capture-1> attribute. The capture<http://dev.w3.org/2009/dap/camera/#dfn-capture-1> attribute enables content authors to indicate the media to be captured and uploaded, specifically still images, video, and audio. Conformant user agents provide their users a more seamless access to the above-mentioned media capture capabilities of the hosting device.

]]

I think this should help with the confusion around the purpose and use of this specification.

First, do you agree with the changes we've made and consider them an improvement?

Second, does this eliminate the need to allow the additional control over specifying audio and video in the capture attribute as you suggested in your Last Call comment, given that Media Capture and Streams offers an alternative? (LC-2637, https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/2637 )

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group





On Sep 12, 2012, at 12:57 AM, ext Doug Schepers wrote:

Hi, Audio WG-

On 9/11/12 10:15 PM, frederick.hirsch@nokia.com<mailto: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<mailto: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