getUserMedia() takes extremely long

[Peter Schraffl]

Hi,

we hope you can help us with a problem we are facing in our angular based web app running in Chrome using WebRTC where the getUserMedia() call takes up to 16 seconds to produce the MediaStream object. So far we have only seen this issue with one of our customers.

We did some debugging and found out that:

• Deactivating certain network adapters on the PC (Windows) we used to run Chrome reduces the required duration.
• The issue is not present when using the same PC to access the same version of our app but hosted on another server - in our test case an internal server instead of the internet facing server of the customer.
  
• It also seems that using Chromes "fake audio devices" reduces the duration.
  

Can anyone tell us what is going on behind the scenes and what might cause this issue?

Might the customers certificate be somehow involved?

Any feedback is appreciated.

Regards

Schraffl Peter

[guest271314]

Do you use a click event on the Web page to call getUserMedia()?

--
You received this message because you are subscribed to the Google Groups "media-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to media-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/media-dev/4bd01372-2286-4d61-854b-ff1e83b6d545n%40chromium.org.

[Peter Schraffl]

No, in this case getUserMedia() it is not directly triggered in the context of a click action, but as mentioned it works with the same client accessing the app on another host and was – so far – never an issue.

[guest271314]

I think they changed sime things recently re the Web page being focused for the Promise to be resolved with a MediaStream.

If you run this at console even when you have permissions granted the stream will be undefined until the Web page gains focus

var p = await navigator.permissions.requestAll([{name: 'microphone'}, {name:'camera'}]);

console.log(p.map(({state}) => state));

var stream = await navigator.mediaDevices.getUserMedia({video: true, audio: true});

[guest271314]

Interestingly even using extension code does not trigger the window to be focused

await chrome.windows.update((await chrome.windows.getLastFocused()).id, {
  focused: true
})

On Tue, Jan 17, 2023 at 5:35 AM Peter Schraffl <Schr...@telecomsoftware.com> wrote:

[Peter Schraffl]

This code gives an exception: “Uncaught TypeError: navigator.permissions.requestAll is not a function”?

…but anyways, the web page has the focus when the issue happens

[guest271314]

What version of Chrome are you testing on? I'm testing on Chromium 111. What happens when you use a click handler on the Web page to get the MediaStream?

[Peter Schraffl]

The “not a function” error was on chrome 109;
The mentioned tests for the issue itself were done in chrome 109; the issue definitely happens only on some client PCs; e.g. no issue on my PC (chrome 109) but reproducible on the PC of a colleague (also chrome 109) in the same network.

Testing it in a click handler using the same host of the customer is not possible as we cannot patch the customers production system to call it inside a click handler, and locally we do not experience the issue.

--
You received this message because you are subscribed to a topic in the Google Groups "media-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/media-dev/LbfK6hZTF-A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to media-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/media-dev/CA%2BsyWAPK-e_kENC%2B7bVfQnkRSr-9WdZxCDqJX0h5sEd4j%3DBkNA%40mail.gmail.com.

[Dale Curtis]

Can you file a bug at https://crbug.com/new with your chrome://gpu information?

Do you see these issues on the sample pages like https://webrtc.github.io/samples/src/content/getusermedia/gum/ ?

+Markus Handell +Ilya Nikolaevskiy 

- dale

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/media-dev/VI1PR0302MB332725F96C10ED53E7CD5465C4C79%40VI1PR0302MB3327.eurprd03.prod.outlook.com.

[guest271314]

> but reproducible on the PC of a colleague (also chrome 109) in the same network.

Kindly post the code to reproduce. Sure sounds like the change to getUserMedia() which does not fulfill the Promise until the user focuses in the target window where getUserMedia() is called.

> Testing it in a click handler using the same host of the customer is not possible as we cannot patch the customers production system to call it inside a click handler, and locally we do not experience the issue.

Then how do you verify the claim?

On Tue, Jan 17, 2023 at 11:31 PM Peter Schraffl <Schr...@telecomsoftware.com> wrote:

[Ilya Nikolaevskiy]

Hello, 

The surest thing to debug this would be to produce the chrome debug logs on the user PC while the issue is reproduced.

Please file a crbug issue with the log and description of what the user was doing and what exactly happened with the chrome.

GetUserMedia may take quite some time if there are a lot of cameras in the system, but ~16 seconds means that there's some serious issue with the camera driver or OS configuration. Might be that some antivirus software is interfering.

However, it's more likely that the page was somehow out of focus and the GetUserMedia was prevented from being resolved immediately due to privacy policy.

--

Best regards,

Ilya

[Peter Schraffl]

Hello,

 

I just wanted to give you a quick update: After doing further testing and analysis it turned out that some higher “background” JS load (and/or localstorage usage) while setting up the WebRTC connection was slowing down the browser and thus also affecting the getUserMedia() performance (or better the completion of the promise). The duration for getUserMedia() shown in the WebRTC internals (and in some of our own console logs) was then leading us into the wrong direction.

Another reason influencing our analysis was one of our test PCs which had a general issue slowing down sometimes and in this way creating some false positives.
Anyways – first tests with a changed version are looking good so far and we are awaiting feedback from our customer. So it seems to be no browser internal issue. Sorry for bothering you.

 

Regards Peter