- From: Josh Soref <jsoref@rim.com>
- Date: Mon, 9 Apr 2012 23:02:54 +0000
- To: Li Li <Li.NJ.Li@huawei.com>, Harald Alvestrand <harald@alvestrand.no>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Li Li wrote: > What if I want to use the video input on foo1 (a webcam with mic) and audio > input on bar3 (a headset)? If you are a web application, why do you care? * You specify technical requirements. * The user-agent provides the user a pretty chooser based on your request * The user makes a relatively informed decision -- If the user selects the audio input from bar3 and the video from foo1, great. If the user didn't want to do that, also great. Consider: 1. App calls getUserMedia() 2. UA returns media sources that satisfy the requirements 3. System frees up another device with a slightly better capabilities 4. Browser wants to be able to substitute devices if it can still satisfy the requirements 5. User gets a <priority> request which interrupts the returned device (maybe it's a phone call). 6. Why shouldn't the design allow the UA to substitute another another source if it satisfies the requirements from 1? Should the browser not be able to provide a better match than the one the app originally requested? Suppose that the user wants to change which video camera they're using from the UA instead of from the app (because occasionally apps are written not to support this feature), should the browser not be able to help the user select a different video camera based on the original capabilities request? Providing an identity feature and making it too easy for apps to code for it will make the use cases above not work. -- I have a feeling that you aren't acting like a web application, which is unfortunate. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Monday, 9 April 2012 23:03:28 UTC