Re: Overconstrained

On 2013-03-26 17:14, Martin Thomson wrote:
> On 26 March 2013 03:45, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:
>> On 2013-03-25 18:35, Martin Thomson wrote:
>>> I would like to propose that we remove optional constraints.
>>>
>>> Sure, it's relatively easy to contrive examples, but I don't believe
>>> that there is anything that a real-world application would unable to
>>> do using a mandatory-only constraints API.
>>
>> [...]  We
>> can't mimic the effect a second run of optional constraints would have on
>> those cameras unless we return both cameras to the app and run the
>> JS-version of the optional constraints as described above.
>
> This is exactly the sort of contrivance I was talking about.  Sure, we
> can prove, mathematically, that mandatory-only produces fewer points
> of articulation, but are you aware of a case where this results in a
> real problem?

I shouldn't have said "I'm not convinced because.." before the statement 
you quoted above. What I meant to say that I think optional constraints 
are completely replaceable one you have a MediaStream, but it's not 
entirely the case at getUserMedia() time. Weather that's actually a 
problem in real life is another question.

What I'm not really convinced about is "uninformed" mandatory 
constraints at getUserMedia() time in general because I think it's easy 
to get it wrong and shut out a lot of users from a service because of a 
badly formed mandatory constraint.

Talking about real life situations.. I think in 90-something% of the 
cases users will either have either one camera (laptop or desktop) or 
two cameras where one camera is pointing at the user and the other 
pointing away from the user (pad or phone). And in the pad/phone case, 
even though the camera pointing away from the user has better specs, 
it's not that suitable for conferencing. With that said, I think the 
camera direction is the single most important constraint at 
getUserMedia() time. If the app has a camera pointing in the right 
direction, it could do some tests on it and determine that it's not good 
enough and tell the user about that in a nice way (and even explain why 
the camera sucks).

So, the remaining problem is: there are more than one camera pointing in 
the desired direction, the user is presented with a choice, and the user 
picks the wrong one. Possible solutions to that problem (a few from a 
very large set):

* Tell the user that the camera wasn't good enough and ask for the other 
camera pointing in the same direction. We know there's one because the 
SourceInfo sequence contains an other camera with the desired direction 
but a different sourceId. We've also talked about revealing more 
information when the user has granted permission to one camera; that 
would make the second attempt fool-proof.

* Convince the user to to grant us access to all cameras pointing in the 
desired direction (Harald's UI proposal). The app can now decide for it 
self which camera to use, or inform the user that none of the cameras 
are good enough. This may be less of a privacy issue than all cameras in 
*any* direction, but may still not appeal to all.

* Have some way of informed filtering. This was already mentioned at the 
end of the first bullet, but only after one device was granted. We could 
have a specific question to get access to information about all cameras 
without having to select a default camera just to get hold of that info. 
There are a lot of ways to do this. One way is to prompt the user if 
it's ok to populate the SourceInfo list with more information. An other 
way is to have a callback (getUserMedia() argument?) that, on a request 
from the selector UI, gets all candidate devices in a sequence, the app 
can then filter out all undesired devices and return the filtered 
sequence. Once the selector UI is presented, the user can choose to show 
all devices or the filtered list.

/Adam

Received on Wednesday, 27 March 2013 07:55:40 UTC