Device Inputs / A/V in the Browser

Session Notes

Session Type: Working group

Session Category: Open Media Developers

Session Leader: Anant Narayanan (Mozilla)

Day: Saturday
Time: 4:00pm – 5:30pm
Room: W303

Description

A/V in the browser is currently mostly a one-way stream, content is served from a site and presented to the user. What if web pages could tap into a user’s local hardware, such as a microphone or webcam?

One of the projects working on a JavaScript API that allows web pages to do this is the Rainbow project from Mozilla for Firefox. Other browsers are also experimenting with such access. We’d like to see this capability evolve to a common standard.

In this session, we’ll:

Discuss the challenges involved in implementing device access in the web browser Discuss the privacy and security implications of exposing microphone & webcam access Gather feedback from web developers on what APIs they would like to see the browser implement Come up with a list of use-cases that are reasonable to target for the first iteration of Device/Media APIs Discuss the different approaches that browsers have taken to provide such an API

Outcome

We aim to build a good understanding of the various issues surrounding device access in the browser, and work towards specifying the different sets of APIs that web developers will find useful to build compelling “two-way” web applications involving the user’s local hardware.

An excellent outcome would be an agreement between different browser vendors on a core set of APIs that should be standardized.


Notes

  • photobooth mozilla labs demo
  • permissions dialog
  • browsers agree on single means to get access to camera/mic, preferably as a media stream object
    • permissions
    • settings (how do they persist)
    • how to map devices to tabs
    • js api/html5
    • two devices from same page (time synch)

permissions

  • tying to domain is not sufficient.
  • should a site be able to force the browser to reprompt for permission to access device
  • session based
  • master swich a-la gps control in android
  • want to separate camera setup dialogs
  • need to be able to faking camera and mic
  • where should api live? under navigator object? already bloated.
  • how handle multiple tabs requesting video? "put the call on hold, or conference them in" what is the metaphor real people will understand?

enumeration

  • can ask for permission for both camera and screen at the same time, not twice
  • only after user has consented
  • delegation of responsibility for picking devices can be delegated to the browser

use cases

  • take a picture from camera
    • hints [mandatory/preferable]
  • output to canvas/webgl
  • time lapse
  • record/review/upload