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

Re: Media Capture API restructured

From: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
Date: Wed, 07 Jul 2010 16:31:02 +0300
Message-ID: <4C348196.9050505@nokia.com>
To: ext Andrei Popescu <andreip@google.com>
CC: Rich Tibbett <rich.tibbett@gmail.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Andrei, Rich,

On 07.07.10 15:24, ext Andrei Popescu wrote:
> > On Wed, Jul 7, 2010 at 12:38 PM, Rich Tibbett
> > <rich.tibbett@gmail.com <mailto:rich.tibbett@gmail.com>> wrote:
> >
> > 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.
>

Those two use cases come to my mind too.

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

I agree that streaming doesn't fit well with HTML forms because of
these reasons.

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

Sounds fine for me. I will such paragraph soon if there are no other
opinions. Thanks.

        -ilkka
Received on Wednesday, 7 July 2010 13:32:07 GMT

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