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

I'm pushing another spec through the process right now (which is how I
know that it's a lot of work).  That group chose to go for everything it
wanted in one version.  It has taken a long time, but because large
parts of the working drafts have been stable for quite a while, there
have been both open source and commercial implementations for a number
of years.  I'm not saying that this is the right way to do things (it
has taken a l-o-o-ng time), but we do have to be aware of the
possibility that there won't be a V2.

- Jim

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Tuesday, August 21, 2012 11:38 AM
To: Jim Barnett
Cc: public-media-capture@w3.org
Subject: 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:47:49 UTC