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

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.

- 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:33:15 UTC