New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 656135 link

Starred by 4 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug



Sign in to add a comment

Audio mirror session ends when navigating away

Project Member Reported by x...@chromium.org, Oct 14 2016

Issue description

Start a mirroring session to a Hendrix. The session ends when navigating to another site.
Not repro every time.
When repros, the session is ended because audio capture error occurs.
 

Comment 1 by mfo...@chromium.org, Oct 14 2016

Labels: M-55

Comment 2 by x...@chromium.org, Oct 28 2016

When navigating to another site while mirroring to Hendrix, WebContentsTracker::RenderFrameDeleted() and WebContentsTracker::WebContentsDestroyed() are called, which indicates no RenderWidgetHost. And therefore session ends.

miu: Do you know possible cause for this? I tried mirroring to ChromeCast and navigated away, these two methods are not called, and instead, WebContentsTracker::RenderFrameHostChanged() is called.

Comment 3 by mfo...@chromium.org, Oct 28 2016

From some code sleuthing, I'm guessing we're not incrementing the capturer count on the WebContents for audio only capture.  That prevents prerendering, which is implemented by swapping WebContents (destroying the current one and swapping in a pre-rendered one on navigation).

Comment 4 by mfo...@chromium.org, Oct 28 2016

It looks like the capturer count is incremented only in the video capture implementation, I strongly suspect my hunch is correct.

Possible solutions:
- Create a fake video capturer just to increment the count
- Plumb in a call to increment the capture count for audio capture as well.

The latter feels better, but I don't see a way to easily get a pointer to the WebContents being captured in the audio capture code I browsed.

Comment 5 by x...@chromium.org, Oct 28 2016

WebContentsAudioInputStream has the access to WebContents through |WebContentsTracker|, which can increment the count. I will try to see if it works.

Comment 6 by mfo...@chromium.org, Oct 28 2016

It appears the capture code appears to be re-purposed for tab muting.  I wonder if we need to also block prerendering for muted tabs.  miu@ should definitely be looped in.
 

Comment 7 by m...@chromium.org, Oct 28 2016

xjz asked me about this. I had two suspicions:

1. The behavior was coincidential (i.e., GetCapturerCount() is *not* a ref-count that must go to zero; and so it could be that sometimes a WebContents was being destroyed due to navigation logic). I chatted with creis@, and confirmed this is not the case.

2. Prerendering: Looks like this *is* the culprit, since prerendering checks the capture count and will abort if >0.

So, talked with xjz about a fix that will make sure the WebContentsAudioInputStream is incrementing the capture count (currently, only the video capture "device" does so).

Comment 8 by x...@chromium.org, Oct 28 2016

Patch out for review: https://codereview.chromium.org/2460033003/
Project Member

Comment 9 by bugdroid1@chromium.org, Oct 29 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c227f1bb6dc4e286df809a97abaef9bdef63c19e

commit c227f1bb6dc4e286df809a97abaef9bdef63c19e
Author: xjz <xjz@chromium.org>
Date: Sat Oct 29 01:09:30 2016

Increment/Decrement capturer count when starts/stops audio capturing.

BUG= 656135 

Review-Url: https://codereview.chromium.org/2460033003
Cr-Commit-Position: refs/heads/master@{#428576}

[modify] https://crrev.com/c227f1bb6dc4e286df809a97abaef9bdef63c19e/content/browser/media/capture/web_contents_audio_input_stream.cc

Comment 10 by m...@chromium.org, Oct 29 2016

Labels: Merge-Request-55
Status: Fixed (was: Started)
We should probably merge into M55 as well.
Is this applicable to all OSs or any specific OS?

Comment 12 by m...@chromium.org, Oct 29 2016

Labels: OS-Chrome OS-Linux OS-Mac OS-Windows
All desktop OSes. (I updated OS labels.)

Comment 13 by dimu@chromium.org, Oct 30 2016

Labels: -Merge-Request-55 Merge-Approved-55 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M55 (branch: 2883)
**** Bulk edit -  please ignore if not applicable ****

Please merge your change to M55 branch 2883 today before 5:00 PM PT or latest by tomorrow, Tuesday (11/01/16) 4:00 PM PT so we can take it for this week Beta release. 

Comment 15 by x...@chromium.org, Oct 31 2016

I am still not allowed to do merging.
Fatal push error. Make sure your .netrc credentials and git user.email are correct and you have push access to the repo.

miu: Can you again help me do this?
git drover --branch 2883 --cherry-pick c227f1bb6dc4e286df809a97abaef9bdef63c19e

Thanks!
Project Member

Comment 16 by bugdroid1@chromium.org, Oct 31 2016

Labels: -merge-approved-55 merge-merged-2883
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7862fa6644ca8da60af147ddbb6a84008bdf276f

commit 7862fa6644ca8da60af147ddbb6a84008bdf276f
Author: Yuri Wiitala <miu@chromium.org>
Date: Mon Oct 31 19:49:30 2016

Increment/Decrement capturer count when starts/stops audio capturing.

BUG= 656135 

Review-Url: https://codereview.chromium.org/2460033003
Cr-Commit-Position: refs/heads/master@{#428576}
(cherry picked from commit c227f1bb6dc4e286df809a97abaef9bdef63c19e)

Review URL: https://codereview.chromium.org/2465013002 .

Cr-Commit-Position: refs/branch-heads/2883@{#392}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/7862fa6644ca8da60af147ddbb6a84008bdf276f/content/browser/media/capture/web_contents_audio_input_stream.cc

Status: Verified (was: Fixed)
Verified with Chrome: 56.0.2922.1					

Sign in to add a comment