W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2010

Re: Media Capture API restructured

From: Andrei Popescu <andreip@google.com>
Date: Wed, 7 Jul 2010 13:24:25 +0100
Message-ID: <AANLkTimr0XsH8vJN-euKWLRpJbG8-HCaZmjsjyhUnRgn@mail.gmail.com>
To: Rich Tibbett <rich.tibbett@gmail.com>
Cc: Ilkka.Oksanen@nokia.com, public-device-apis@w3.org
Hi,

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?
>
>
Yes, that's one type of usage. The other is by getting the File object via
HTMLInputElement::files and using that with the FileReader, etc.


> 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?
>
>
Hmm, the current form-based approach draft doesn't mention streaming in any
way. For clarity, maybe it should have a paragraph pointing to the html5
device spec, saying that streaming is handled there?

Thanks,
Andrei
Received on Wednesday, 7 July 2010 12:24:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:11 GMT