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, <[email protected]> wrote:
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
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
