RE: Moving getUserMedia to best-effort

> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> 
> On 07/28/2012 01:18 AM, Travis Leithead wrote:
> > Since operations that obtain the capabilities and assign the constraints
> > will be interacting with the local media resources that are furnishing
> > the initial MediaStreamTrack(s) of a LocalMediaStream, and given that
> > LocalMediaStream objects are strongly tied to local media resources
> > (even though their track lists are mutable over time), I propose the
> > following:
> >
> > interface LocalMediaStream : MediaStream {
> >
> >      void stop ();
> >
> >      // proposal ******************************
> >
> >      MediaStreamConstraints? getUserMediaCapabilities();
> >
> >      void applyConstraints(MediaStreamConstraints? constraints);
> >
> > };
> 
> I think that something like this should be added. But isn't there a
> fingerprinting issue with exposing all capabilities? An alternative, or
> perhaps complement, that we've been discussing is an API for inspecting
> (introspect?) the MediaStreamTrack. It would not expose capabilities,
> but rather what the track is delivering right now (resolution,
> frame-rate, ....).

My suggestion is that only the approved devices will reveal their 
capabilities. This at least prevents "drive-by" fingerprinting--users 
will have to opt-in via the browser (or device's) user-content prompt.

Of course we're talking about "capabilities" in the most general sense
at this point. We should start to get more concrete with what we mean.

I think that resolution is a critical one for starters. Does it make sense to
return resolution capabilities that are ranges or specific supported "modes"?
For example, would a camera return:
{ minPixelWidth: 320,
maxPixelWidth: 1080 }
or a set of supported resolutions, since the camera won't support the 
in-between resolutions:
[ { pixelWidth: 320 }, { pixelWidth: 640 }, {pixelWidth: 800} ] 
perhaps paired with vertical resolutions?

Thoughts on this?



> As for the applyConstraints: I think the discussion has led me to that
> this is something that should be done on a MediaStreamTrack level, not
> MediaStream.

Can be done. I'll revise the proposal...

Received on Monday, 6 August 2012 18:02:43 UTC