1909222 - getusermedia takes more than 10 s

Status: NEW

(Core :: WebRTC, defect, P3)

Description

[Paul Menzel]

Steps to reproduce:

Access https://webrtc.github.io/samples/src/content/getusermedia/gum/ and click on Open camera.

Actual results:

It takes more than ten seconds until the browser permission dialog is shown.

Expected results:

The dialog should be shown instantly like in Brave for example.

This results in a bad user experience with video conferencing systems like BigBlueButton – related comment.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Michael Froman [:mjf]]

Paul, thank you for your report!

On what platform are you seeing the slow repsonse time? I notice you marked this as Firefox 130, which is Nightly. Have you also seen the same behavior on Release (currently 128)?

Comment 3

[Paul Menzel]

Attachment: Output of `about:support`

Michael, thank you for your reply.

(In reply to Michael Froman [:mjf] from comment #2)

On what platform are you seeing the slow repsonse time?

Debian sid/unstable with GNOME and X.Org. I attach the output of about:support.

I notice you marked this as Firefox 130, which is Nightly. Have you also seen the same behavior on Release (currently 128)?

Yes, it has been happening since several releases, including current release 128.0.2.

Comment 4

[Michael Froman [:mjf]]

Paul, since you say it has regressed, would you mind running mozregression to find a commit range? See: https://mozilla.github.io/mozregression/install.html

Having a commit range for the regression will be super valuable to help track down what caused the issue.

Also, following the instructions here, to get a profile of the issue would help us diagnose the issue.

Running with a fresh profile temporarily to see if that improves the issue would also give us useful data.

Comment 5

[Paul Menzel]

(In reply to Michael Froman [:mjf] from comment #4)

Paul, since you say it has regressed, would you mind running mozregression to find a commit range? See: https://mozilla.github.io/mozregression/install.html

Having a commit range for the regression will be super valuable to help track down what caused the issue.

I’ll see, if I find time.

Also, following the instructions here, to get a profile of the issue would help us diagnose the issue.

https://share.firefox.dev/3Lzv2Mx

Running with a fresh profile temporarily to see if that improves the issue would also give us useful data.

I’ll see what I can do.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mjf, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Michael Froman [:mjf]]

Paul, thank you for the profile. We can see that the 10s is spent mostly in querying the camera capabilities. This is likely slower for us because of Bug 1286945.

Comment 8

[Paul Menzel]

Michael, thank you for the analysis. Excuse my ignorance, but what does querying more resolutions have to do with it?

Comment 9

[Michael Froman [:mjf]]

Looking at the profile, on your machine, each of these queries spends a lot of time in the ioctl system call (see here), and we're making that call 195 times (once for each resolution across each of the supported video formats). What we don't have visibility into is why this call is taking so long for your particular setup.

This code was updated in May of 2023, going from 5 to 15 supported video formats, which explains the regression you've noticed. With all other things equal, on your machine that would mean going from roughly 3 seconds to 10 seconds. This is code imported from libwebrtc, so we are exploring options to patch this and/or contribute a fix back to the upstream project that would improve how the query is done.

Comment 10

[Paul Menzel]

Thank you very much for the detailed feedback. I understand the problem now. I am going to look into strace, if that can support the analysis.

Comment 11

[Paul Menzel]

Just for my understanding, you have not found a system where you can reproduce this, is that correct?

Comment 12

[Michael Froman [:mjf]]

(In reply to Paul Menzel from comment #11)

Just for my understanding, you have not found a system where you can reproduce this, is that correct?

Sorry for the delay in responding. No, we haven't been able to reproduce, but that doesn't mean it we're not interested in improving the situation. For comparison, below I've included a profile from my linux box where the same enumeration completes in just under 3s.
https://share.firefox.dev/46TVES1