Re: Media Capture API restructured

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

> On Wed, Jul 7, 2010 at 2:31 PM, Ilkka Oksanen <Ilkka.Oksanen@nokia.com>wrote:
>
>>
>> On 07.07.10 15:24, ext Andrei Popescu wrote:
>>
>>>
>>>  > 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.
>>
>
> What I had in mind was re-writing the introduction to say that the input
> approach does not provide access to a device's camera or microphone per se,
> just a special super type of File called MediaFile for audio/*, video/* and
> image/* files. That would clarify things a bit.
>
>
Sounds reasonable, although I still think we should link to <device> for
people interested in streaming.


> Also, could MediaArray be renamed to MediaList in line with the File API
> spec?
>
>
Sounds fine.



> Regarding the 'capture' attribute perhaps a better approach would be <input
> type="file" accept="video/*;source=capture">? I'm not sure that the capture
> attribute adds anything important to the file upload element.
>
>
As mentioned before, that's the approach we took in Android (except that the
source can be camcorder / camera / microphone, rather than capture). It's
easy to use and easy to implement.



> Finally, could most of the Form-based access spec be subsumed in to the
> HTML5 spec. Currently we are duplicating the definition of the MediaFile
> element in both versions of the Media Capture specifications. It would
> probably be best to define MediaArray, MediaFile, etc in one place and then
> point the other spec (or the HTML5 spec itself) to the WebIDL definitions of
> these interfaces.
>
>
Yep, integrating this into HTML5 would be ideal.

Andrei