W3C home > Mailing lists > Public > public-media-capture@w3.org > June 2012

Re: mplementation suggestions

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 08 Jun 2012 12:43:36 +0200
Message-ID: <4FD1D758.2040400@alvestrand.no>
To: public-media-capture@w3.org
On 06/07/2012 05:15 PM, Anant Narayanan wrote:
> On 6/7/12 7:58 AM, SUN Yang wrote:
>>   I am not sure how the resources behave when busy, but I often use 
>> chrome to test webrtc service, I often in 1 tab open a page then the 
>> page gets stream from the camera, and in another tab i open another 
>> page I can also get stream from the second page.
>>
>>   And i think it will be common the same camera will be shared by 
>> different page in browser, as I always do in webrtc demo development.
>
> We can certainly implement a "development mode" where this is allowed, 
> but in the normal-default case, I think we should enforce busy 
> resources. If we don't it will be easy for users to forget which pages 
> are currently using their camera and it is hard to convey the fact 
> that the same stream is used in two different pages to the user.
>
> One concession we could make though, it to allow the same stream to be 
> used in two different tabs but only as long as they're both from the 
> same origin.

Same origin works for me; it allows the debug / test case.

(not sure of my language here) it would be as if the first opener placed 
a restriction on the camera saying "only accessible from my origin". It 
also allows people to create applications that explicitly need to get 
the camera from multiple tabs, while preventing different applications 
that don't know each other from messing each other up (for instance, by 
zooming/panning the camera,  playing with focus mode, or flashing).


>
> -Anant
>
>>   So I suggest we do not specify that second call to camera will 
>> counter "busy",but may promote to user that the resources currently 
>> used by which application, which has more practical meanings.
>>
>>   Yang (Huawei)
>
Received on Friday, 8 June 2012 10:44:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC