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

VERIFIED FIXED in mozilla20

Status

()

Core
WebRTC: Audio/Video
P2
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: jsmith, Assigned: jesup)

Tracking

19 Branch
mozilla20
All
Windows 7
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
Keywords: regression
(Reporter)

Comment 1

6 years ago
Created attachment 674380 [details]
Testcase
Would be good to know what has been caused this.
Keywords: regressionwindow-wanted
(Assignee)

Comment 3

6 years ago
[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).
(Reporter)

Comment 4

6 years ago
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?
(Reporter)

Comment 6

6 years ago
(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.
(Reporter)

Updated

6 years ago
Whiteboard: [getUserMedia] [blocking-gum-]
(Reporter)

Updated

6 years ago
Whiteboard: [getUserMedia] [blocking-gum-] → [getUserMedia] [blocking-gum+]
(Reporter)

Updated

6 years ago
Priority: -- → P1
(Reporter)

Updated

6 years ago
Priority: P1 → P2
(Assignee)

Comment 8

6 years ago
Some of the MediaStream/gUM changes may have removed buildup of frames in the stream.  Please retest
Assignee: nobody → jsmith
Keywords: qawanted
(Reporter)

Comment 9

6 years ago
(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
(Assignee)

Comment 10

6 years ago
Created attachment 696573 [details] [diff] [review]
Drop cached image when we stop capturing + debugs
(Assignee)

Comment 11

6 years ago
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
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Updated

6 years ago
Flags: in-testsuite-
Keywords: verifyme
(Reporter)

Comment 14

6 years ago
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.