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

Issue 596516 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug


Participants' hotlists:
Audio-Focus


Sign in to add a comment

Determine how MediaStream producers should interact with MediaSession.

Project Member Reported by dalecur...@chromium.org, Mar 21 2016

Issue description

http://crrev.com/371870 added MediaSession support for MediaStream producers; the most notable being WebRTC. This behavior was reverted in http://crrev.com/382108 because of an increasing number of issues with expected behavior (primarily around two active camera apps).

See issue 581983, issue 595297, and issue 595659.

Some deeper thought about how MediaStreams should interact with the MediaSession (or whether they should at all) needs to be done. Here are some of the open questions to start:

- What should happen when two cameras are active on the system? Most notably around tab switching. Switching to the foreground attempts to unpause a background camera which is hidden and thus can't be played (otherwise it might steal the foreground sessions audio focus).

- What should happen when the user starts a music playback while recording?

- What should be done about having both a "recording icon" and a "media session icon" in tray?

Many more I'm sure. It's important to think about this as the MediaSession team looks more into a world where only one active audio session may be allowed. Others may be ducked or paused.
 
Labels: -OS-Chrome M-56 OS-All
Owner: zqzh...@chromium.org
Cc: zqzh...@chromium.org avayvod@chromium.org
 Issue 639874  has been merged into this issue.
Project Member

Comment 3 by bugdroid1@chromium.org, Oct 20 2016

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

commit a923571ee803000f4116e0267b0fcdcad5d982e0
Author: zqzhang <zqzhang@chromium.org>
Date: Thu Oct 20 23:05:38 2016

Tuning WebRTC audio focus type

This CL changes the audio focus type for WebRTC:

* On desktop, WebRTC will take persistent audio focus (when
  default MediaSession is enabled). WebRTC will suspend other
  tabs when it starts, and will not be interrupted by other media
  activities.
* On Android, WebRTC will not bother MediaSession
  since the audio focus is already handled for the input stream.
  The behavior is the same as Desktop (with default MediaSession
  enabled).

BUG= 596516 

Review-Url: https://chromiumcodereview.appspot.com/2428353005
Cr-Commit-Position: refs/heads/master@{#426635}

[modify] https://crrev.com/a923571ee803000f4116e0267b0fcdcad5d982e0/content/browser/media/session/media_session.cc
[modify] https://crrev.com/a923571ee803000f4116e0267b0fcdcad5d982e0/content/renderer/media/webmediaplayer_ms.cc

Cc: kavvaru@chromium.org
Labels: Needs-Feedback
Tested the issue on Windows 10, Mac 10.11.6 using steps mentioned in merged bug 581983.

1. Go to https://apprtc.appspot.com > Click on the "JOIN" option available. 
2. "ALLOW" Chrome to use your camera and microphone when pop-up appears 
3. Click on the link available at bottom of page> Click on join> Wait for sometime
4.Not observed any issue

Please find the attached screen cast for the same.Not observed any issue on reported version 50.0.2633.0 from issue 581983.

zqzhang@ Please check the screen cast and update if anything missed here.Please provide us the steps to verify the issue from test team end.

Thanks,
596516.mp4
12.3 MB View Download
Project Member

Comment 5 by bugdroid1@chromium.org, Oct 21 2016

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

commit 2e14f672e9c90c414fb752ead4d355194cc00dc6
Author: zqzhang <zqzhang@chromium.org>
Date: Fri Oct 21 18:14:37 2016

Take one-shot focus for WebRTC on Android

There is a conflict in two recent CLs:
https://chromiumcodereview.appspot.com/2437963002
https://chromiumcodereview.appspot.com/2428353005,
in which WebRTC does not take audio focus both for the input stream and
the output stream. This CL lets WebRTC take audio focus on Android from
MediaSession again to fix the issue.

BUG= 596516 

Review-Url: https://chromiumcodereview.appspot.com/2437343002
Cr-Commit-Position: refs/heads/master@{#426845}

[modify] https://crrev.com/2e14f672e9c90c414fb752ead4d355194cc00dc6/content/renderer/media/webmediaplayer_ms.cc

Tested the issue on Mac 10.11.6 using chrome version 56.0.2900.0 with the steps mentioned in comment #4.Not observed any issue in reported version 50.0.2633.0 also.

zqzhang@ please provide steps to verify the issue from test team end.

Thanks,
Ah, sorry. It's an experimental feature (default MediaSession on Desktop) for UX to experiment with, and haven't get into production yet.

If you want to test it, follow the instructions here:
https://docs.google.com/a/google.com/document/d/1Zg94Hm6HGMc0GKHIyY1Z11L8yTyX8fm6ccEsmnCNivQ/edit?usp=sharing
Just realized WebRTC will show a media notification after that change. We should fix that.
Project Member

Comment 9 by bugdroid1@chromium.org, Nov 10 2016

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

commit 89ec74b2c84ed550a4eb1de5b338e18252ecd291
Author: zqzhang <zqzhang@chromium.org>
Date: Thu Nov 10 15:11:02 2016

Implement one-shot audio focus inside MediaSession

This CL implements one-shot audio focus type inside MediaSession,
instead of letting players joining MediaSession using Persisitent
type, while ignoring audio focus changes.

In this CL, when a one-shot player joins MediaSession,
MediaSession will takes audio focus and becomes active. However
when a MediaSession has one-shot players, it will become
uncontrollable.

BUG= 596516 , 619084 

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

[modify] https://crrev.com/89ec74b2c84ed550a4eb1de5b338e18252ecd291/content/browser/media/session/media_session_impl.cc
[modify] https://crrev.com/89ec74b2c84ed550a4eb1de5b338e18252ecd291/content/browser/media/session/media_session_impl.h
[modify] https://crrev.com/89ec74b2c84ed550a4eb1de5b338e18252ecd291/content/browser/media/session/media_session_impl_browsertest.cc
[modify] https://crrev.com/89ec74b2c84ed550a4eb1de5b338e18252ecd291/content/browser/media/session/pepper_playback_observer.cc
[modify] https://crrev.com/89ec74b2c84ed550a4eb1de5b338e18252ecd291/content/common/media/media_player_delegate_messages.h
[modify] https://crrev.com/89ec74b2c84ed550a4eb1de5b338e18252ecd291/content/renderer/media/webmediaplayer_ms.cc
[modify] https://crrev.com/89ec74b2c84ed550a4eb1de5b338e18252ecd291/media/base/media_content_type.h

Comment 10 by perkj@chromium.org, Nov 14 2016

Cc: hta@chromium.org
CC hta. 
Neither me or magjed is actively working on WebRTC in Chrome. 
Labels: -M-56 M-57
Bumping to M57. Please update if that's wrong.
Labels: -M-57 M-58
Labels: -M-58 M-59
Owner: mlamouri@chromium.org
Labels: -M-59 M-60
Labels: -Needs-Feedback -M-60
Owner: ----
Project Member

Comment 17 by sheriffbot@chromium.org, Apr 26 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)

Sign in to add a comment