Closed Bug 782191 Opened 12 years ago Closed 12 years ago

Only begin streaming video/audio from camera/recording device when needed through mozGetUserMedia

Categories

(Core :: WebRTC: Audio/Video, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: jsmith, Assigned: anant)

Details

(Whiteboard: [getUserMedia], [blocking-gum-])

Attachments

(1 file)

In comparing Chrome's production implementation to our Nightly implementation, one big difference I noticed was that they only appear to request access to the camera when they actually need it, not just immediately grab and lock the resource right after the mozGetUserMedia callback (i.e. lazy loading). This seems logical that they do this, as it prevents use of a resource that's not actively in use. We should follow suit here and only lock the camera for use when we actually need it post a mozGetUserMedia callback, and not do what we are doing now.
Whiteboard: [getUserMedia]
Keywords: qawanted
Confirmed this happens with the attached test case. We haven't started the content at all this test case - we've only made the gUM call and did console output. We shouldn't make the camera active in this case.
Keywords: qawanted
Attached file Test Case
Assignee: nobody → mreavy
Whiteboard: [getUserMedia] → [getUserMedia], [blocking-gum-]
Bug 802411 should have fixed this.
Assignee: mreavy → anant
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Keywords: verifyme
Verified on 10/19 build. This needs a test too.
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Keywords: verifyme
No longer valid behavior given changed requirements, so no need to track for in-testsuite.
Flags: in-testsuite? → in-testsuite-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: