- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 18 May 2012 14:07:27 +0200
- To: Cullen Jennings <fluffy@iii.ca>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 05/17/2012 09:03 PM, Cullen Jennings wrote: > > On May 8, 2012, at 8:06 AM, Stefan Hakansson LK wrote: > >> Basically getUserMedia can have two different meanings: >> >> 1. It is merely a way for the user to give consent to the >> application to use devices (and the user is involved in selecting >> which devices). The devices would not be reserved, activated or >> start producing data until there is a consumer (e.g. a video >> element) for the MediaStream delivered by getUserMedia. >> >> 2. It is rather a way to grab those resources, activate them and >> have them start producing data (regardless of whether the data is >> consumed or not). > > Regardless of what it is (and I always assumed it was 2), we need the > API to provide a function to do 2. Otherwise you can't make apps that > don't get their resources stollen. I'm not sure we need an API that > provides 1 but perhaps we do. THis was discussed at the telco May 9th; the result was that 2. was the way forward. Anant got the actions to draft text, action 2 and 3 here: http://www.w3.org/2011/04/webrtc/mediacap/track/actions/open Stefan > >> >> (I'm sure there are also other interpretations). I think that these >> aspects have not been discussed very much, but they have big >> implications. >> >> For example, if we assume meaning 2. above, an application could >> not be written to do getUserMedia at load time (to have that done >> if/when there is a need to use the MediaStream) as this would block >> other applications from using e.g. camera and mike. >> >> On the other hand, if we assume meaning 1., the situation could be >> that once the application needs the MediaStream, the devices are >> blocked by another application (which is using e.g. camera and >> mike), so there would be an error even though getUserMedia worked >> out OK. >> >> I also think it has implications on when to release devices. With >> meaning 1., it would probably make sense to release devices once >> there are no consumers of the MediaStream(s) they generate. With >> meaning 2., devices should probably be released only if the user >> revokes (via the browser chrome) the consent to use them or if all >> MediaStream's that the device delivers to have "ended" (by the app >> calling the "stop" method). >> >> I think it would make sense to spend a little while discussing this >> tomorrow (and on this list!). >> >> Br, Stefan >> >
Received on Friday, 18 May 2012 12:07:58 UTC