Re: [capture] A couple of editorial comments

Tobie

comment inline, I think you are asking useful questions that reflect the clarity of use cases or lack thereof, not trolling in my understanding of the term :)

regards, Frederick

Frederick Hirsch
Nokia



On Nov 27, 2012, at 3:28 PM, ext Tobie Langel wrote:

> Thanks for your answers, Frederick.
> 
> On 11/27/12 8:21 PM, "Frederick.Hirsch@nokia.com"
> <Frederick.Hirsch@nokia.com> wrote:
> 
>> On Nov 21, 2012, at 7:38 AM, ext Tobie Langel wrote:
>> 
>>> 
>>> - The wording in the abstract seems to imply HTML Media Capture is only
>>> useful to immediately upload captured content. It might be worth
>>> mentioning it gives the document access to the capture content through
>>> the
>>> File API which allows client-side manipulation and storing (in
>>> IndexedDB).
>> 
>> The primary purpose is to upload immediately captured content. Why not
>> use the FileAPI directly otherwise?
> 
> How can the FileAPI launch capture control types?

it cannot as far as I know, but it can upload files that are in an appropriate format or location, isn't that so?
> 
> The use case is to take a picture, then manipulate and store it locally.

Let's see, wouldn't this use case be three steps for a web application:

1. take a picture - HTML Media Capture
2. Manipulate - e.g. web application uses Web Intents to invoke manipulation program, local or remote
3. Store locally - web application uses another API (IndexedDB API?) to store

Thus for the first step, capture, the focus of HTML MediaCapture, there is no support for local or remote manipulation (other than what is integrated into the device UI itself, though this UI could provide various features)

My understanding is that capture and upload are integrated without the ability for an explicit distinct local manipulation step.

I.e. when I select the camera via the UA in response to an HTML Media Capture element the picture is taken by the user (using camera controls as appropriate) with immediate upload.

Thus no step to run an additional local program for red-eye removal for example (if this is what you meant by manipulation)

maybe we  need clarity on this in the document and it is possible I could be confused.

> 
>> That said, we should not make changes which lose the primary purpose
>> though we could clarify that file upload is also possible
>> 
>>> 
>>> - I am not sure I fully understand the sentence "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."
>> 
>> What is not clear? It says that using forms one can upload material
>> captured by device mechanisms but cannot have fine grained control like
>> handling tracks etc.
> 
> It is unclear to me whether the limited control refers to that of the end
> user or the author. I'm also not sure what "the default offered by the
> device" means in that context. (Not trolling, I really don't understand.
> :-/ )

what I mean specifically to give one example, is that with HTML Media Capture you are stuck with the integrated camera and microphone for video capture for example - what you get is a recorded video with the
'default' integrated audio and video stream. This is very limited control (and in fact Doug asked why not offer more detailed control).

This is one thing that distinguishes the supported use cases for HTML Media Capture versus getUserMedia, which could allow a more advanced user use case, where i decide to have a higher quality microphone on a stand closer to the subject and then combine that audio stream with the image stream to achieve a capture.

Thus there is limited control over what is captured, both for the user and the web page author as neither can use HTML Media capture to achieve the external microphone capture use case (unless again the local camera app includes  it)

does this make sense?

> 
> Thanks,
> 
> --tobie
>

Received on Tuesday, 27 November 2012 20:50:09 UTC