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

On 08/21/2012 05:57 PM, Mandyam, Giridhar wrote:
> 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.
There's no outside force setting those priorities ... we as a group set 
them. So it's not a matter of understanding, it's a matter of deciding.
>
> 2) You included MediaStream definition, but did not include LocalMediaStream definition for V1.  LocalMediaStream is still in scope for V1 - right?
Yes. They're closely enough entangled that I didn't think of separating 
them out.
> 3) Can we assume that the "out" features are baseline enhancements to the spec for V2?
Yes, that's what I was proposing.
>
> 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?
If it all works out (always an if), the Media Capture spec will contain 
the language registering those constraints with IANA, so conflict is 
impossible.
>
> 5) What is the reasoning behind making constraints optional only in V1?
Some people have argued that they do not want to implement constraints 
at all. Both those lines are aimed at figuring out if we can find a 
reasonable set of requirements on the implementations.
> 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 16:12:19 UTC