- From: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 30 Nov 2011 19:06:34 +0100
- To: public-webrtc@w3.org
On 11/30/2011 05:59 PM, Randell Jesup wrote: > Hoisting to a new thread with a better title... Good idea! > > On 11/30/2011 9:35 AM, Stefan Håkansson LK wrote: > > On 11/29/2011 11:02 PM, Randell Jesup wrote: > >>> We wrote some stuff up at > >>> <https://labs.ericsson.com/developer-community/blog/dmp> if someone is > >>> interested. > >> > >> Yes, interesting. The alternative would be for the app to have a > >> control/button/etc ("media") which re-opens the getUserMedia requester. > >> > >> Question: how should this this interact with Fullscreen mode in > >> browsers? And also what about mobile, where people often want browsers > >> to run virtually full-screened? (This closely mirrors the already-open > >> question of how we provide an always-visibile indication that mics > >> and/or cameras are active.) It should be possible, for example, for the > >> app to invoke this requester as well. > > > > This is a difficult one (regardless of how getUserMedia is handled). > > Should there be some visual (overlayed) indication? > > As mentioned, we haven't specified how an implementation will let the user > know the camera/mic are active, but we need them to have that (and the > ability to mute or kill it). Overlaying has issues unless we spec exactly > how and where it's overlaid (since the app writer need to know how to > avoid it), or have a way for the app writer to adapt to the actual overlay > (much more flexible, but tougher to get right by the app). Yes, there are issues, but what are the options? > > > A means for the app to bring up the device selection pane sounds good to > > me. > >> > >> How would it deal with multiple cameras/mics? > > > > That's touched upon in the UI walkthrough video where we have three > > getUserMedia() requests and two cameras. > > What could be discussed is an additional parameter to getUserMedia() > > where the app could label the source. > >> > >> How does a user look up something in another tab while talking? > > > > This should work just fine. The other tab would not have the status view > > (but the tab which has an ongoing audio/video session should have an > > indicator that audio/video is being captured - but the full screen case > > is difficult). > > There was an implication of muting when not focused - true? People have > said things assuming both muting on tab-switch and no muting on tab-switch. If I remember right, the discussion at TPAC went along the line that you should not mute at tab-switch (since a very normal behavior is to put another tab in focus during a conversation to look things up, just as you say!). > FYI, I don't consider the color change on the tab to be sufficient or > discoverable enough by general users. I think Anant showed something like this, and that it was generally liked at the meeting. > > There's certainly a use-case for people to keep talking while the tab/window > is not focused ("let me look that up in Google Maps..."). > > >> > >> What happens if the user focuses another window? > > ...or minimizes the browser. Should there be an indication in the system > > tray? > > Probably. Also what if another window obscures the browser window or where > the indicator is? Yeah, difficult to handle. >
Received on Wednesday, 30 November 2011 18:07:35 UTC