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

: mplementation suggestions

From: Sunyang (Eric) <eric.sun@huawei.com>
Date: Fri, 08 Jun 2012 07:31:28 +0000
To: Anant Narayanan <anant@mozilla.com>, SUN Yang <sun.yang.nj@gmail.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-id: <9254B5E6361B1648AFC00BA447E6E8C32AEA4F33@szxeml545-mbx.china.huawei.com>

: Anant Narayanan [mailto:anant@mozilla.com] 
ʱ: 201267 23:15
ռ: SUN Yang
: public-media-capture@w3.org
: Re: mplementation suggestions

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.

[yang] chrome will promote a red ball in the sys tray is camera is used by browser. So we can know the camera is still by used, which is out of scope of standard. What's more, implement a different remind mechanism is not difficult I think.

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.
[yang] this is ok. But I still think 2 different stream is used by the same tab is possible, for 3D......


>   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 07:35:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:10 UTC