New issue
Advanced search Search tips

Issue 880757 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
guidou@chromium.org
niklase@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Desktop capture video track from chrome.desktopCapture is muted intermittently when app is minimized/backgrounded

Reported by devteam_...@netop.com, Sep 5 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Platform: 10718.88.2 (Official Build) stable-channel veyron_minnie

Steps to reproduce the problem:
1. Start desktop capture with a Chrome App (like in the sample) using chrome.desktopCapture and getUserMedia, no audio
2. Open a DevTools instance for the app, to observe the console. 
3. Minimize the app window and focus a different app, but not the DevTools window or the Chrome browser (e.g., the Chrome OS File Manager)
4. In the DevTools console, received "mute" and "unmute" events will be logged to the console.

What is the expected behavior?
The desktop sharing video track should run without being muted, even if the app window is in the background

What went wrong?
The video MediaStreamTrack from the desktop capture stream receives intermittent muted/unmuted events (every 3 seconds or so, but sometimes is muted for even longer intervals).

Did this work before? Yes M67

Does this work in other browsers? N/A

Chrome version: 68.0.3440.106  Channel: stable
OS Version: 68
Flash Version: 

Since desktop capture apps are rarely in the foreground (if ever), the desktop capture video stream should not be throttled. The attached sample is the one from the official repository, with the addition of the muted/unmuted event handlers.

This works on Windows 10, seems to be a Cros issue only
desktop-capture.zip
564 KB Download

Comment 1 by guidou@chromium.org, Sep 5

Components: -Blink>MediaStream Blink>GetUserMedia>Desktop

Comment 2 by niklase@chromium.org, Sep 14

Status: Available (was: Unconfirmed)

Comment 3 by devteam_...@netop.com, Oct 30 

Additionally to the above, from Chrome OS 69, the "ended" event also gets gets fired occasionally for the desktop capture video track, even though the user never revokes the permission and the app HAS the front-end.
This happens quite often, though unfortunately at random and therefore cannot be consistently reproduced at this point.

It would be helpful to get an indication as to what could cause the desktop capture stream to change its readyState to ended, when the user never actively terminates desktop sharing.
According to https://w3c.github.io/mediacapture-main/#event-mediastreamtrack-ended , the reason can only be one of the following:

- the user revoked the permissions, 
- the source device has been ejected,
- the remote peer permanently stopped sending data

Since the stream is a local screen capture, and the used did not interact with the device, none of the above apply.
►

Sign in to add a comment