Re: A sketch of a V1 of the media capture API specifciation

On 08/21/2012 05:31 PM, Jim Barnett wrote:
> My experience is that it takes a lot of time and work to go through the
> full W3C standardization process.  Do we really want to do it twice (and
> take the chance of there not being a V2 at all)?  Would it be possible
> to have an "internal" V1 (i.e. a working draft that contained a stable
> specification of the features you list below)?  We could then proceed to
> an "internal" V2, and have that be the only draft that goes through the
> full standardization process.
If people are happy with that, we could. If others who watch us from 
outside have dependencies on us getting past certain stages, or if 
others don't believe anything is stable until it's passed some stage, I 
assume they will raise their voices and tell us.

Dom might want to tell us whether there are IPR implications of not 
going through the CR/and so on stages.

           Harald

>
> - Jim
>
> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Tuesday, August 21, 2012 11:20 AM
> To: public-media-capture@w3.org
> Subject: A sketch of a V1 of the media capture API specifciation
>
> Based on what we have so far in the spec, our current implementers'
> choices, arguments on the list, and the needs we percieve as minimal,
> here's a sketch of a proposal for the question of "what's in V1 of the
> spec" - the stuff that we aim towards with our current milestones.
>
> This implies a V2, which means that we need to define milestones for
> when we want that done.
> *
>
>
>        Minimum feature set v1:
>
> In:
>
>    * getUserMedia
>    * MediaStream definition
>    * Connecting MediaStream to media element via createObjectURL(stream)
>    * Two basic constraints: resolution and frame rate for video (height,
>      width, aspect ratio, frame rate) x (min, max)
>        o Implementation should not be required ("I support default only"
>          is allowed)
>        o Only optional - not mandatory?
>
> Out:
>
>    * Recorder
>    * Direct assignment to media element
>    * Image capture API
>
>
> Open:
>
>    * Application of new constraints to an already existing
> LocalMediaStream
>    * Check/adjust audio level in audio tracks
>
> *
> It's possible that the audio level stuff can be dealt with by saying "we
>
> assume the browser also implements the WebAudio API". Adding such a
> dependency should be an explicit TF decision.
>
> Harald, for the chairs
>
>
>
>

Received on Tuesday, 21 August 2012 15:38:44 UTC