Camera and mic control scenario of WebRTC

[Steven]

Hi all,

We are working on WebRTC on B2G now. I'd like to discuss the scenario
when the app is going to background.
When the app calls GetUserMedia to get camera/mic resources then it
switches to background. What should we do?
I think we should turn off the camera and mic. Because
1. privacy
2. We have only one HW
3. power consumption

The ways to turn off camera and mic may
1. Having a media service to control the HW resources. As I know, Sotaro
will implement this service.
2. Before 1 is done, apps or WebRTC API should handle the situation.

On B2G, camera app listens to "mozvisibilitychange" event to turn on/off
the camera.
But WebRTC cannot request apps to listen to "mozvisibilitychange" since
it may be called in the web page.
I don't think every page will handle it correctly. So that I think
WebRTC API should handle it in the short term, ex, in MediaManager.
How do you think?

Please give me some feedback.
Thanks.

--
Steven
Mozilla Taiwan

[Randy Lin]

For VOIP or Audio Recording on mobile devices,
It's common for user to switch the application to background and do other things.

Randy

_______________________________________________
dev-media mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

[Chiajung Hung]

Agree, and I think sometimes we may want to keep receive even in background.

For example, if I join a conference by WebRTC, and I hear something interesting and want to take some note for it. I may bring up app like Evernote and write down some keyword for later reference.

I don't think it is good to just stop everthing when switched to background.

Best Regards,
Chiajung

[sl...@mozilla.com]

Hi all,

As for the behaviour of backgrounding a real-time streaming video/audio chatting app, my suggestion here would be "Stops the camera, but keeps the Mic". It meets all your concerns about "privacy, resource releasing, and power consuming".

Yet it doesn't save as much resource or power as stopping both camera and mic, but it sure saves more then holding those two. In most cases, users in a realtime video chatting scenario are able to see both images of themselves and the other. This ensures users what they are showing. Hiding the app should stop the camera, otherwise we should still show the image of users side.

While the behaviour of mic should mimic answering a phone call, even a feature phone can look up contacts while holding the call.

Hope that this helps!

Thanks,
Shelly

[Eric Rescorla]

FWIW, Facetime's current behavior, is to freeze the current
camera image but maintain the microphone. It would be
easy for us to do the same.

-Ekr

[Randell Jesup]

On 5/6/2013 1:50 AM, Eric Rescorla wrote:
> FWIW, Facetime's current behavior, is to freeze the current
> camera image but maintain the microphone. It would be
> easy for us to do the same.

(I'll note that Facetime can be considered a "trusted" app...)

If we do that, we obviously need to keep a visible indication that
there's an active mic sending to the other person (notification bar I'd
assume).

On desktop, we can't really do this well - we could do it for switches
from one tab to another (though it might not be the commonly expected
behavior, as most standalone and plugin video chat apps (Hangouts,
Skype, etc) don't do this), but there's no easy way to know if our
window is obscured, and if it is, how much obscuring is "enough" to
pause the video? This was discussed in the standards groups as well,
and the general consensus there IIRC was that we had to be able to leave
it active, and that we'd write language stating that indication that the
mic/camera are active must remain visible in the browser chrome.

One random example: voice command and gesture assistants. You run an
app in a background tab that listens for voice commands and watches for
gesture commands.

It's also complicated since this is defining how getUserMedia() works,
not PeerConnection.

The other option would be to freeze video (or video and audio), unless
the app has a higher permission level granted by the user. In theory you
could use the chrome recording indicator as a way to grant background
access, or you could say "trusted" apps can use an API to say "I want
background access" and untrusted apps that use it would pop a chrome
request for such access.

Also: some of the above reasoning is specific to desktop and doesn't
apply well to mobile. On mobile, the default could be the same as
Facetime, or it could always force that with no way to override.

Randell

>
> -Ekr
>
>
> On Sun, May 5, 2013 at 9:48 PM, <sl...@mozilla.com> wrote:
>