Closed Bug 804760 Opened 7 years ago Closed 7 years ago

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

Categories

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

19 Branch
All
Windows 7
defect

Tracking

()

VERIFIED FIXED
mozilla20

People

(Reporter: jsmith, Assigned: jesup)

Details

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

Attachments

(2 files)

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.
Keywords: regression
Attached file Testcase
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.
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-]
Whiteboard: [getUserMedia] [blocking-gum-] → [getUserMedia] [blocking-gum+]
Priority: -- → P1
Priority: P1 → P2
Some of the MediaStream/gUM changes may have removed buildup of frames in the stream.  Please retest
Assignee: nobody → jsmith
Keywords: qawanted
(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
Keywords: qawanted
QA Contact: jsmith → rjesup
Assignee: nobody → rjesup
QA Contact: rjesup → jsmith
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+
https://hg.mozilla.org/mozilla-central/rev/d2b38501de2c
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Keywords: verifyme
Verified on 1/29 build with Win 7.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.