W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2011

Re: CHANGE: Use a JS Object as an argument to getUserMedia

From: Anant Narayanan <anant@mozilla.com>
Date: Thu, 06 Oct 2011 13:10:56 -0700
Message-ID: <4E8E0B50.4010106@mozilla.com>
To: public-webrtc@w3.org
On 10/6/2011 9:38 AM, Adam Bergkvist wrote:
> Timothy B. Terriberry wrote:
>> I'm not sure this is really a problem: the request indicates
>> whether you asked for audio and/or video, and tracks can be
>> pre-created that simply don't reach the appropriate ready
>> state until the user gives consent (if ever). You can still
>> argue about whether you want the user to be able to consent
>> to "just audio" or "just video" when you asked for both, and
>> what should be done in that case. I'll let Anant tackle that issue.
>
> A stream may contain any number of audio and video tracks which makes it hard to pre-create tracks even if you know what types the stream may contain. The question about "just audio" and "just video" is tricky. On one hand, it's not good if a user can't use an application because it requests video but the user doesn't have a camera, but on the other hand, the application may behave strangely if an expected component is missing.

I agree that the question is tricky, but it is something that we no 
doubt have to handle. I think that we absolutely should let the user 
deny either video or audio even if the application requested both (what 
are the arguments for not allowing this?). The real question is of how 
this information is relayed back to the application.

The way I'd like to see that happen is to let the application ask for 
what it wants via it's initial call to getUserMedia but not expect to 
get everything it asked for (in similar vein to the hints proposal), and 
deal with the situation in the event listener. For example, if the 
application asked for both audio and video and the user denied video, we 
still change the readyState of the MediaStream but the application will 
notice that a video track was not added. At this point it may display an 
error to the user, or proceed if it is able to function with an audio 
track only.

This requires us to expose more information in a MediaStreamTrack 
object, at the very least, if a given track contains audio, video, or both.

(On a side note, if the user chooses instead to transmit video from a 
local file instead of the webcam, it is still a success scenario and the 
UA should return a MediaStreamTrack object of type video. I don't think 
there's a huge use-case for a web app being able to know if the video in 
a given track is really from the webcam or not. We really do want users 
to be able to "fake" input and feel that this is missing feature in the 
current Geolocation API).

Regards,
-Anant
Received on Thursday, 6 October 2011 20:11:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC