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

Harald,

I also have reservations about doing two versions of the specification, 
for reasons already presented. Additionally, Firefox has implemented 
some portions of features that the proposal moves to v2, so I think we 
are overestimating the amount of work needed to add those into the spec.

On 8/21/12 8:20 AM, Harald Alvestrand wrote:
>   * 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?

I agree that this is the bare minimum needed. We should also arrive at 
the specific set of constraints to be supported.

> Out:
>
>   * Recorder
>   * Direct assignment to media element
>   * Image capture API

Direct assignment to a media element is a fundamental issue, not an 
afterthought. I don't believe that has been consensus on using 
createObjectURL, in fact, both Opera & Firefox are shipping gUM with 
direct assignment *only*. (I am happy to present my objections to 
representing a MediaStream as a URL).

The Image capture API is a use-case that is sorely needed by developers, 
and Firefox Nightly has an experimental version of the feature already. 
Combined with Rich's recent proposal to the list w.r.t. a Camera API, I 
think we can arrive at something solid fairly quickly.

I'm okay with pushing recording to "v2", but my reservations against 
doing a v2 still holds. Recording can also be achieved with output 
objects like <video>, so *some* solution that fulfils a large number of 
use cases is possible without any change to the gUM spec.

Regards,
-Anant

Received on Tuesday, 21 August 2012 19:01:44 UTC