- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Tue, 21 Aug 2012 08:46:20 -0700
- To: "Harald Alvestrand" <harald@alvestrand.no>
- Cc: <public-media-capture@w3.org>
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