Re: Moving getUserMedia to best-effort

On 08/06/2012 08:02 PM, Travis Leithead wrote:
>> 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.
I think the sentiment I heard when we discussed this last was that once 
you've got the video stream, you already know exactly what camera it is 
(there are all sorts of fingerprinting-useful information that actually 
appear *in the video stream*), so any attempt at preventing further 
fingerprinting is completely futile.
>
> 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?
Min and max only are simpler, and don't require us to support set notation.

I'd expect most reasonable usages of constraints to supply either a min 
or a max, but not both; if one is looking at application requirements 
rather than "force the camera into this mode", that seems a reasonable 
assumption.

I could be wrong....
>
>
>
>> 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 Wednesday, 8 August 2012 05:31:21 UTC