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

Hello Harald,
Some questions:

1) I am not against this proposal, but can we have a refined charter expressing deliverables for V1 and V2 and target dates?   I realize that there is no requirement for a formal charter in a task force, but I think it would be helpful particularly for the newcomers like myself to understand what features will be targeted and when.

2) You included MediaStream definition, but did not include LocalMediaStream definition for V1.  LocalMediaStream is still in scope for V1 - right?

3) Can we assume that the "out" features are baseline enhancements to the spec for V2?

4) Constraints (specifically keys associated with constraints) are defined in the RTCWeb registry currently, according to section 5.2.2 of the current spec.  If the constraint keys called out in section 5.2.2 are not consistent for some reason with the RTCWeb registry, would the Media Capture API spec take precedence?

5) What is the reasoning behind making constraints optional only in V1? 

Thanks,
-Giri

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Tuesday, August 21, 2012 8: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:57:45 UTC