Steps: 1. Call gUM with video: true and immediately put the stream result into a video tag and start playing the video (see attached test case) Expected: The video should start playing showing you from your camera with no hangs. Actual: The video hangs on startup for a second or two (it's noticeable), but then starts playing.
Would be good to know what has been caused this.
[17:30] jsmith jesup: I just tested my testcase on the latest Aurora - looks like I don't get a delay at all on Aurora, but on Nightly, I get about 1 - 3 second hang that's noticable. So yeah, it looks like a regression. [17:53] jesup jsmith: nightly + my audio+video patches starts *faster* than aurora on my mac. (not very different on first open, but much faster on subsequent ones).
Actually, I know what's going on here now. This isn't a regression. Here's the steps to reproduce I did that's actually different what's stated above that generates the bug: 1. Load the attached test case and enable the camera 2. Let the video stream run for a few seconds 3. Reload the test case page 4. Allow camera access Result - The appearance of a noticeable hang seen is not because of a performance issue with loading the stream from camera, it's actually because I'm seeing bits of the camera stream from step #2, then the camera turns on, and I see the stream from the camera actively in real-time. So the bug is here I think is that we're leaving behind stream bits from the first page view when it gets viewed a second time upon a page reload.
Keywords: regression, regressionwindow-wanted
Summary: Calling gUM with video: true - a noticeable hang is seen upon starting the video → Calling gUM with video on a page, reloading the same page - camera stream bits from the first run is seen quickly before switching to the real-time active stream
That means it only happens when .stop() is not called, right?
(In reply to Henrik Skupin (:whimboo) from comment #5) > That means it only happens when .stop() is not called, right? In this case, I don't believe I called stop() at all, so yes.
You could try to update your testcase with an onunload event handler which will stop the media stream. If that fixes the problem on reload we would have identified the fault.
Whiteboard: [getUserMedia] [blocking-gum-] → [getUserMedia] [blocking-gum+]
Some of the MediaStream/gUM changes may have removed buildup of frames in the stream. Please retest
Assignee: nobody → jsmith
(In reply to Randell Jesup [:jesup] from comment #8) > Some of the MediaStream/gUM changes may have removed buildup of frames in > the stream. Please retest I can still reproduce on the 12/15/2012 build on Win 7 64-bit.
Assignee: jsmith → nobody
Created attachment 696573 [details] [diff] [review] Drop cached image when we stop capturing + debugs
Comment on attachment 696573 [details] [diff] [review] Drop cached image when we stop capturing + debugs Now that we keep a cached image around (so NotifyPull has something to get), we have to make sure we drop the image when we stop capturing. We can still get a flash *if* we re-use the same video element; reloading the page avoids it. I suspect this is due to internal buffering in the <video> element. Also added some more log messages, and made the frame logging available by default at NSPR log level 6.
Attachment #696573 - Flags: review?(tterribe)
Attachment #696573 - Flags: review?(tterribe) → review+
Target Milestone: --- → mozilla20
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Verified on 1/29 build with Win 7.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.