804760 - 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

Status: VERIFIED FIXED

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

Description

[Jason Smith [:jsmith]]

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.

Comment 1

[Jason Smith [:jsmith]]

Attachment: Testcase

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Would be good to know what has been caused this.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

[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).

Comment 4

[Jason Smith [:jsmith]]

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.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That means it only happens when .stop() is not called, right?

Comment 6

[Jason Smith [:jsmith]]

(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.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Some of the MediaStream/gUM changes may have removed buildup of frames in the stream.  Please retest

Comment 9

[Jason Smith [: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.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Drop cached image when we stop capturing + debugs

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d2b38501de2c

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d2b38501de2c

Comment 14

[Jason Smith [:jsmith]]

Verified on 1/29 build with Win 7.