Re: Media Capture API restructured

Thanks for the updates! I can appreciate how much work goes in to this ;-)

There seems a subtle demarkation should be made between the <input
type="file" accept="audio/*"> approach defined in this spec and proposed
usage of a <device type="media"> element. IMO, both elements would have
similar but subtle differences in their intended usage.

It seems the <input> based capture model is a method for a user to create an
on-demand image/audio/video 'file' that can then be shared *in its entirety*
with a webapp at the point it has been fully captured. That works because
the input element is a form-based control and on form submit, the user's
video will be uploaded as if it were a regular file. I expect this is the
intended usage?

Streaming media on the other hand doesn't, and probably shouldn't, end up in
a form-based file element because streaming media does not need to be
integrated with web forms. The data in a streaming session is bursty and
timely and typically has no longevity beyond the current streaming event.
That doesn't fit in with an <input> element which has a one-time  onsubmit
and has longevity by submitting all stream data to the web server when that
may not necessarily be required. The typical use case for media streaming
would be obtain stream data, render/send the stream data and then either
save or discard the used stream data, much like the process is described in
the HTML Device draft [1].

Maybe there is potential to separate the subtleties of the pre-captured
stream file vs. the streaming media stream use cases with the <input> and
<device> elements respectively?

- Richard

On Wed, Jul 7, 2010 at 9:13 AM, <Ilkka.Oksanen@nokia.com> wrote:

> Hi,
>
> Based on the decision during the previous call, I have now split the Media
> Capture spec into two:
>
> Form Based Access: http://dev.w3.org/2009/dap/camera/Overview.html
> Programmatic API: http://dev.w3.org/2009/dap/camera/Overview-API.html
>
> Comments welcome. ViewFinder interface is postponed to level 2. Regarding
> the form based access I ended to introduce a new boolean attribute called
> 'capture' for <input type=file>. Current text in HTML5 defines exhaustive
> list of accepted comma separated tokens for the accept attribute. I don't
> think it's appropriate to extend that list blindly in a separate spec.
>
> Related to this, I believe the question remains if the form based spec
> should stay in its own document in the first place or should it be actually
> merged to HTML5 spec. I guess it can be now seen as a simple HTML5
> extension. I think we should at least check now that there are no blocking
> issues with this kind of approach.
>
>           -ilkka
>