Re: Media Capture API restructured

On Wed, Jul 7, 2010 at 12:38 PM, Rich Tibbett <rich.tibbett@gmail.com>wrote:

> 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
>
>
[1] http://dev.w3.org/html5/html-device/


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