- From: Anant Narayanan <anant@mozilla.com>
- Date: Thu, 06 Oct 2011 13:10:56 -0700
- 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