Closed Bug 1992567 Opened 1 year ago Closed 11 months ago

Memory leak while screen sharing

Categories

(Core :: WebRTC: Audio/Video, defect, P2)

Product:
Core
Component:
WebRTC: Audio/Video
Version:
Firefox 144
Platform:
Desktop
Unspecified
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
147 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- wontfix
firefox-esr140 --- fixed
firefox145 --- wontfix
firefox146 --- wontfix
firefox147 --- fixed

People

(Reporter: unusualcrow, Assigned: pehrsons)

References

Details

Attachments

(7 files, 2 external files, 1 obsolete file)

memory-report.json.gz
360.18 KB, application/gzip
Details
248724.fxsnapshot
285.44 KB, application/octet-stream
Details
Firefox 2025-10-15 16.06 profile.json.gz
3.62 MB, application/gzip
Details
Htop window showing process memory usage
256.02 KB, image/jpeg
Details
Memory report collected during screen sharing
112.06 KB, application/gzip
Details
about_support_info.txt
35.50 KB, text/plain
Details
aboutsupport.txt
48.47 KB, text/plain
Details
Attached file memory-report.json.gz —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:144.0) Gecko/20100101 Firefox/144.0

Steps to reproduce:

Go to https://gifcap.dev/ and record screen.
Alternatively, use screen sharing via Discord or Microsoft Teams.

Using Hyprland Wayland compositor on Arch Linux. Issue was also reported on KDE on Arch Linux Forums.
Reproduced in Firefox, Firefox Developer Edition, and Firefox Beta

Actual results:

System memory usage rapidly increases by 200-300 MB/s until screen recording is stopped or systems runs out of memory and processes are terminated, session freezes or crashes, etc.

Expected results:

Memory does not leak.

I built Firefox with the recommended options for Valgrind and ran it with this command:
G_SLICE=always-malloc valgrind --leak-check=yes --trace-children=yes --smc-check=all-non-file --vex-iropt-register-updates=allregs-at-mem-access --show-mismatched-frees=no --read-inline-info=yes --log-file=./valgrind.log firefox

Here is the output file after reproducing the issue:
https://files.catbox.moe/yzky45.log

Hope this helps. I'm not experienced with Valgrind whatsoever.

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Valgrind doesn't report such leak but just tiny 383 KB one:

==121908==    definitely lost: 383,274 bytes in 2,569 blocks
==121908==    indirectly lost: 1,226,873 bytes in 17,205 blocks
==121908==      possibly lost: 4,159,208 bytes in 15,071 blocks
==121908==    still reachable: 10,582,880 bytes in 73,344 blocks

Seems to be directly related to https://gifcap.dev/ and the JS code there. Looks like the site allocates lot of memory. Not sure it's directly related to screen recording:

25,211.48 MB (100.0%) -- explicit
├──12,582.47 MB (49.91%) ── heap-unclassified
├──12,565.25 MB (49.84%) -- window-objects/top(https://gifcap.dev/, id=91)
│  ├──12,562.75 MB (49.83%) -- active/window(https://gifcap.dev/)
│  │  ├──12,562.12 MB (49.83%) -- js-realm(https://gifcap.dev/)
│  │  │  ├──12,561.94 MB (49.83%) -- classes
│  │  │  │  ├──12,561.35 MB (49.82%) -- class(ArrayBuffer)/objects
│  │  │  │  │  ├──12,561.33 MB (49.82%) ── gc-buffers/elements/normal
│  │  │  │  │  └───────0.02 MB (00.00%) ── gc-heap
│  │  │  │  └───────0.59 MB (00.00%) ++ (7 tiny)
│  │  │  └───────0.18 MB (00.00%) ++ (5 tiny)
│  │  └───────0.62 MB (00.00%) ++ (3 tiny)
│  └───────2.50 MB (00.01%) ++ js-zone(0x7f641ef53d00)
└──────63.77 MB (00.25%) ++ (24 tiny)

Do you see that on any other site?

Flags: needinfo?(unusualcrow)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #5)

Do you see that on any other site?

This occurs with Discord and Microsoft Teams screen sharing as well.

Flags: needinfo?(unusualcrow)

Can you try different compositor like Mutter/KDE? You may need to install whole environment as you may see issues with XDG portals which is a system component securing the screen sharing.
Thanks.

Flags: needinfo?(unusualcrow)

Did you try to minimize memory usage before saving memory report?

Severity: -- → S3

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

Can you try different compositor like Mutter/KDE? You may need to install whole environment as you may see issues with XDG portals which is a system component securing the screen sharing.
Thanks.

The other user who reported this issue here is on KDE.

(In reply to Thinker Li [:sinker] from comment #8)

Did you try to minimize memory usage before saving memory report?

No, but here's a report where I did, using my ordinary Firefox Dev Edition. Didn't look like it cleared any memory.
https://files.catbox.moe/ld76rv.gz
(file is gzipped)

Flags: needinfo?(unusualcrow)

Does reloading the page and minimizing memory work?
Could take a snapshot of memory at Memory tab of Web Developer Tools (ctrl-shift-I)?
It is even better with Record call stacks being enabled before screen sharing.
The snapshot will help us to identify if it is an issue of the service itself.

Attached file 248724.fxsnapshot —

(In reply to Thinker Li [:sinker] from comment #10)

Does reloading the page and minimizing memory work?
Yes, it does. The memory usage is retained when reloading but does clear once I hit minimize.

Could take a snapshot of memory at Memory tab of Web Developer Tools (ctrl-shift-I)?
It is even better with Record call stacks being enabled before screen sharing.
The snapshot will help us to identify if it is an issue of the service itself.
I've attached it with Record call stacks enabled.

(screwed up my formatting there, sorry)

Can you try to use Firefox profiler (https://profiler.firefox.com/docs/#/./guide-getting-started) and check the memory usage there? https://profiler.firefox.com/docs/#/./memory-allocations ?
Because it looks like you're getting the allocation from the web site and not from Firefox itself. Also can you check about:processes page for details?
Thanks.

Flags: needinfo?(unusualcrow)
Flags: needinfo?(unusualcrow)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #14)

Can you try to use Firefox profiler (https://profiler.firefox.com/docs/#/./guide-getting-started) and check the memory usage there? https://profiler.firefox.com/docs/#/./memory-allocations ?
Because it looks like you're getting the allocation from the web site and not from Firefox itself. Also can you check about:processes page for details?
Thanks.

Uploaded is the profile while capturing the screen with gifcap. I could see memory tick upwards in the profiler but didn't see any allocations actually going through that amount of memory. about:processes also reports memory usage coming from gifcap.

Okay, tentatively moving to DOM for further investigation.

Component: Widget: Gtk → DOM: Core & HTML

Do you require any more debug info to narrow down this bug? If so, what and how could I provide this?
I observe this issue in Arch Linux running KDE (Wayland) and obviously with FF 144.

System memory usage rapidly increases by 200-300 MB/s until screen recording is stopped or systems runs out of memory and processes are terminated, session freezes or crashes, etc.

Are you saying memory is returned as soon as one of those things happen, or only after all of them happen?

On its face, this website records your screen over time and plays back the entire recording at the end. Where do you expect it to keep this recording if not in memory?

Websites are allowed to use a lot of memory, for instance to keep a recording. It is only a "leak" if it fails to return the memory on completion.

(Of course it's not great if Firefox crashes at the end. If this report is about the crash then please submit a crash log from about:crashes)

Teams or Discord should not have this issue however. Does it repro with https://jan-ivar.github.io/dummy/gdm.html ?

Flags: needinfo?(unusualcrow)

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #19)

System memory usage rapidly increases by 200-300 MB/s until screen recording is stopped or systems runs out of memory and processes are terminated, session freezes or crashes, etc.

Are you saying memory is returned as soon as one of those things happen, or only after all of them happen?

On its face, this website records your screen over time and plays back the entire recording at the end. Where do you expect it to keep this recording if not in memory?

Websites are allowed to use a lot of memory, for instance to keep a recording. It is only a "leak" if it fails to return the memory on completion.

(Of course it's not great if Firefox crashes at the end. If this report is about the crash then please submit a crash log from about:crashes)

You make a good point that gifcap isn't exactly a great test case.
To answer your question, memory is returned if I stop the recording, but never if I let it continue.
Memory not being forcibly returned by Firefox when reaching 100% results in my compositor entirely crashing in most cases when I've let any of the sites I mentioned run my system out of memory during screen recording. In the best case, Firefox alone crashed. I'm not sure if this is expected or not.
The larger issue at hand is that screen sharing, rather than recording, obviously shouldn't be storing every recorded frame in memory in the first place, and whatever is happening there to inflate memory is making that feature completely unusable.

Teams or Discord should not have this issue however. Does it repro with https://jan-ivar.github.io/dummy/gdm.html ?

Teams & Discord are definitely the main issue and I'm happy to provide logs using one of those. The behavior with those sites seems to be the exact same that gifcap shows as far as how quickly memory inflates. I can't reproduce the issue with the site you provided; memory remains totally stable there.

Flags: needinfo?(unusualcrow)

After analyzing the memory snapshot provided in comment #11, I think that the accumulated ArrayBuffers in the frames array should be intentional behavior by the web application. All these frame are kept in an array by a callback function. As long as the web application doesn't release this array frames, these ArrayBuffers will not go away. it bascially confirms comment #19

Having the same issue on Arch Linux with Wayland. When sharing my screen in Microsoft Teams (web app), Firefox quickly starts consuming all available RAM until either the tab crashes or the whole system locks up, while screen sharing in Google Meet works fine and doesn’t cause any memory issues.

On my setup, the problem also reproduces with https://gifcap.dev/

Happy to provide logs or any other info to help reproduce the issue.

(In reply to Bulat Maksudov from comment #23)

Having the same issue on Arch Linux with Wayland. When sharing my screen in Microsoft Teams (web app), Firefox quickly starts consuming all available RAM until either the tab crashes or the whole system locks up, while screen sharing in Google Meet works fine and doesn’t cause any memory issues.

On my setup, the problem also reproduces with https://gifcap.dev/

Happy to provide logs or any other info to help reproduce the issue.

Could you share a profile with logging?

  • Setup a call on Microsoft Teams, disable cam and mic
  • On about:logging select the WebRTC preset and start
  • Setup screen capture such that it leaks memory and run for a few seconds
  • Back on about:logging stop the profiler
  • Upload the profile making sure to include all hidden threads (for privacy use a clean Firefox instance with no other tabs)
  • Share the link here, thanks
Flags: needinfo?(b.maksudov)

I could not reproduce on Teams in a Mozilla-built Nightly. Could you try that config too, to narrow things down?

(In reply to Andreas Pehrson [:pehrsons] from comment #25)

I could not reproduce on Teams in a Mozilla-built Nightly. Could you try that config too, to narrow things down?

Did a quick test in Nightly. The issue is reproducible only when another participant joins the meeting.
If I just start a meeting and share my screen alone, there’s no memory leak.
As soon as I join the same meeting from my phone, RAM usage starts ballooning rapidly.

I’ll upload logs later today. Thanks for checking this.

(In reply to Andreas Pehrson [:pehrsons] from comment #24)

(In reply to Bulat Maksudov from comment #23)

Having the same issue on Arch Linux with Wayland. When sharing my screen in Microsoft Teams (web app), Firefox quickly starts consuming all available RAM until either the tab crashes or the whole system locks up, while screen sharing in Google Meet works fine and doesn’t cause any memory issues.

On my setup, the problem also reproduces with https://gifcap.dev/

Happy to provide logs or any other info to help reproduce the issue.

Could you share a profile with logging?

  • Setup a call on Microsoft Teams, disable cam and mic
  • On about:logging select the WebRTC preset and start
  • Setup screen capture such that it leaks memory and run for a few seconds
  • Back on about:logging stop the profiler
  • Upload the profile making sure to include all hidden threads (for privacy use a clean Firefox instance with no other tabs)
  • Share the link here, thanks

Here’s the performance profile from Nightly:
https://share.firefox.dev/43hUQpA
Test steps:

  • Started a call in Teams
  • Joined the same meeting from my phone
  • Started performance logging
  • Began screen sharing

RAM usage jumped from around 8 GB to 12 GB within a few seconds.
Let me know if anything else is needed.

Flags: needinfo?(b.maksudov)

(In reply to Bulat Maksudov from comment #27)

Here’s the performance profile from Nightly:
https://share.firefox.dev/43hUQpA
Test steps:

  • Started a call in Teams
  • Joined the same meeting from my phone
  • Started performance logging
  • Began screen sharing

RAM usage jumped from around 8 GB to 12 GB within a few seconds.
Let me know if anything else is needed.

Thank you for the profile! It shows minimal memory usage in all our processes though. Per System Monitor (or equivalent, sorry I use Ubuntu) which process is using all this RAM?

Flags: needinfo?(b.maksudov)

FWIW, I've seen some high memory usage with Zoom web client on linux. When it happens, GTT value is very high in radeontop.
There were some driver (amdgpu) level fixes to memory leaks recently, IIRC, but not sure they are related.

Performance profiles aren't very good with memory tracking. about:memory would be more reliable.

Jan, have you seen this perhaps?

Flags: needinfo?(jgrulich)

(In reply to Andreas Pehrson [:pehrsons] from comment #30)

Jan, have you seen this perhaps?

No, I have not. Trying it in Firefox or Chromium on the WebRTC gUM Test page or Google Meet, I don't see memory consumption being increased while sharing the screen.

Flags: needinfo?(jgrulich)
Flags: needinfo?(b.maksudov)

Thanks. Would you mind sharing your about:support too? Maybe it has enough details so I could set my system up to reproduce this.

Flags: needinfo?(b.maksudov)
Attached file about_support_info.txt —

Added. Let me know if anything else is needed.

Flags: needinfo?(b.maksudov)

This could be related to bug 1996020.

See Also: → 1996020

I tried to reproduce in multiple ways, but still no luck.

I tried Firefox 144 from Fedora 43, tested with Google Meet (also joined with another participant) and WebRTC gUM test page and I don't see any rapid memory increased. Same with Firefox Nightly. I tried to reproduce with MS Teams, but in Firefox 144 from Fedora it doesn't do anything when I try to share my screen and in Firefox Nightly it seems to do something, but joining as another participant, I still don't see anything so not sure it's working. This is on Fedora 43 with KDE Plasma 6.5, kernel 6.17 and an Intel card.

(In reply to Jan Grulich from comment #37)

I tried to reproduce in multiple ways, but still no luck.

I tried Firefox 144 from Fedora 43, tested with Google Meet (also joined with another participant) and WebRTC gUM test page and I don't see any rapid memory increased. Same with Firefox Nightly. I tried to reproduce with MS Teams, but in Firefox 144 from Fedora it doesn't do anything when I try to share my screen and in Firefox Nightly it seems to do something, but joining as another participant, I still don't see anything so not sure it's working. This is on Fedora 43 with KDE Plasma 6.5, kernel 6.17 and an Intel card.

The easiest way I found to reproduce it in a screen share scenario is to make an empty Discord server, join a voice channel, and share my screen there. Doesn't require any other participants.

Attached file aboutsupport.txt —

Additional about:support from my usual dev edition instance in case it helps. Reproduced with or without addons enabled and on other fresh builds as well - see farther up in discussion.

(In reply to Zoey from comment #38)

(In reply to Jan Grulich from comment #37)

I tried to reproduce in multiple ways, but still no luck.

I tried Firefox 144 from Fedora 43, tested with Google Meet (also joined with another participant) and WebRTC gUM test page and I don't see any rapid memory increased. Same with Firefox Nightly. I tried to reproduce with MS Teams, but in Firefox 144 from Fedora it doesn't do anything when I try to share my screen and in Firefox Nightly it seems to do something, but joining as another participant, I still don't see anything so not sure it's working. This is on Fedora 43 with KDE Plasma 6.5, kernel 6.17 and an Intel card.

The easiest way I found to reproduce it in a screen share scenario is to make an empty Discord server, join a voice channel, and share my screen there. Doesn't require any other participants.

I can reproduce it with that.

(In reply to Jan Grulich from comment #40)

(In reply to Zoey from comment #38)

(In reply to Jan Grulich from comment #37)

I tried to reproduce in multiple ways, but still no luck.

I tried Firefox 144 from Fedora 43, tested with Google Meet (also joined with another participant) and WebRTC gUM test page and I don't see any rapid memory increased. Same with Firefox Nightly. I tried to reproduce with MS Teams, but in Firefox 144 from Fedora it doesn't do anything when I try to share my screen and in Firefox Nightly it seems to do something, but joining as another participant, I still don't see anything so not sure it's working. This is on Fedora 43 with KDE Plasma 6.5, kernel 6.17 and an Intel card.

The easiest way I found to reproduce it in a screen share scenario is to make an empty Discord server, join a voice channel, and share my screen there. Doesn't require any other participants.

I can reproduce it with that.

Sorry, I can't. I gave up testing too early, I saw my memory went up by hundreds like twice and assumed it's going to continue, but no it doesn't. I tested it again with Nightly and our RPM package and still can keep streaming my screen without memory usage being increased over time.

Ok I have a hunch. What CPU do you have? Can you check when reproducing, what resolution is sent according to about:webrtc?

I double checked your profile and it suggests I may be right. The GMP process that runs the OpenH264 encoder may be having trouble keeping up. We might have to rate-limit it. See in the profile: the content process thread talking to the GMP process, and the GMP process itself.

Assignee: nobody → apehrson
Status: UNCONFIRMED → ASSIGNED
status-firefox145: --- → wontfix
status-firefox146: --- → affected
status-firefox147: --- → affected
status-firefox-esr115: --- → wontfix
status-firefox-esr140: --- → affected
Component: DOM: Core & HTML → WebRTC: Audio/Video
Ever confirmed: true
Flags: needinfo?(b.maksudov)
Priority: -- → P2
Hardware: Unspecified → Desktop

(In reply to Andreas Pehrson [:pehrsons] from comment #42)

Ok I have a hunch. What CPU do you have? Can you check when reproducing, what resolution is sent according to about:webrtc?

I double checked your profile and it suggests I may be right. The GMP process that runs the OpenH264 encoder may be having trouble keeping up. We might have to rate-limit it. See in the profile: the content process thread talking to the GMP process, and the GMP process itself.

I have a Ryzen 7 3700X. I wasn't able to locate the resolution in about:webrtc but I'm quite sure I'm sharing my full screen at 4K 3840x2160p so you may be on to something. Perhaps Bulat is running a similar scenario.

(In reply to crohmann from comment #18)

Do you require any more debug info to narrow down this bug? If so, what and how could I provide this?
I observe this issue in Arch Linux running KDE (Wayland) and obviously with FF 144.

Are you also on a relatively high resolution? Do you see the same behavior when sharing only a window? It seems only sharing my full screen is an issue.

Flags: needinfo?(crohmann)

I will assume this regressed in bug 1429390. It sounds in that bug like we cannot just make it synchronous again, unless we audit through the code and verify there is no way we may sync-dispatch from the GMP thread to main.

That's unfortunate though, as webrtc encoders generally are sync. The libwebrtc VideoStreamEncoder may allocate new frame buffers dynamically as needed if encoded resolution does not match incoming resolution, and theres' no back-pressure mechanism here with async encoding. That said, I am not sure we hit that path in practice or end up hitting another downscaling path earlier in the pipe. The back-pressure mechanisms seem mainly bitrate related, though in a higher layer there's this that end up causing frame drops here but given how the logic works it assumes that encodes are synchronous.

Auditing it is, I guess.

Depends on: 1999747

Bug 1999747 should be the better fix but isn't trivial. I'll land a mitigation here in the near-term.

I am using Intel i7-8550U. Could not find resolution in about:webrtc, but assuming it uses full display resolution, that would be 2560x1440.
The weird part here is that the sharing was working before about 1 month ago in same setup, so I assume something changed?

Flags: needinfo?(b.maksudov)

(In reply to Bulat Maksudov from comment #47)

I am using Intel i7-8550U. Could not find resolution in about:webrtc, but assuming it uses full display resolution, that would be 2560x1440.
The weird part here is that the sharing was working before about 1 month ago in same setup, so I assume something changed?

It's certainly curious that the encoder going async would lead to issues reported 7 years later for a fairly widely used feature. I would imagine there was some other trigger involved.

(In reply to Bulat Maksudov from comment #47)

I am using Intel i7-8550U. Could not find resolution in about:webrtc, but assuming it uses full display resolution, that would be 2560x1440.
The weird part here is that the sharing was working before about 1 month ago in same setup, so I assume something changed?

Same issue for me with a Ryzen 7 7800X3D on 4k. Screen sharing in teams with other participants worked just fine like 1 month ago but now it runs into some memory leak.
I also don't see a resolution in about:webrtc

Ok, I can reproduce.

STR:

  • Load https://jsfiddle.net/pehrsons/fLcjn9tr
  • Under Source's 2nd dropdown (resolution), pick Screen. Next dropdown (framerate) pick 60 FPS.
  • Under Transceiver pick H264.
  • Click "Start".
  • Approve the prompts, picking a screen running at 4k@60.

Expected:
2nd video element (remote side of peer connection) is ~identical to 1st video element (local capture)

Actual:
2nd video element lags further and further behind, indicating a backlog of encode jobs into the GMP encoder building up.

Interestingly, I don't see this increase in memory consumption in System Monitor's process list. htop however shows the GMP process owning the bulk of the memory.

If I limit the number of frames in flight to the GMP process to 1, I see in the OpenH264 log:

[OpenH264] this = 0x0x7c8d2d0bea00, Debug:[Rc] Frame timestamp = 3972027395727, iDid = 0,skip one frame due to target_br, continual skipped 1 frames

and then we stop encoding, because there is no Encoded callback to tell us it was processed...

Looking into the OpenH264 plugin, it does have one hook for the skipped frame case. I.e., GMPVideoi420FrameImpl::Destroy without an Encoded callback. Seems fiddly but doable to retrofit a Skipped callback or so on top of that. Best would perhaps be if we could add that to the GMP plugin API directly.

If I limit to 5 frames in flight, we no longer have the leak, at least. But we better hope that OpenH264 doesn't decide to drop 5 frames in a row.

Depends on: 1999970

This avoids an ~unbounded memory leak when OpenH264 is not able to keep up with
encoding in real-time.

This allows the GMP client (in this case the WebRTC GMP encoder) to know whether
the encoder plugin decided to drop a frame. This lets us avoid flushing the
encoder with more encode jobs than it can handle.

Attachment #9526469 - Attachment description: Bug 1992567 - Enforce a hard limit of 5 frames in flight in WebRTC GMP encoder. r?aosmond → Bug 1992567 - Enforce a hard limit of 1 frame in flight in WebRTC GMP encoder. r?aosmond,bwc

Here's a profile of a local debug build with the two patches posted as of now, doing 4k 60FPS capture, encoded as 3 simulcast streams (4k 60FPS) at varying bitrates: https://share.firefox.dev/3JKYn9t
OpenH264 drops lots of frames as screen capture is set to drop frames for rate control by default. Now the encoder doesn't get flooded so memory use is manageable.

(In reply to Andreas Pehrson [:pehrsons] from comment #51)

Looking into the OpenH264 plugin, it does have one hook for the skipped frame case. I.e., GMPVideoi420FrameImpl::Destroy without an Encoded callback. Seems fiddly but doable to retrofit a Skipped callback or so on top of that. Best would perhaps be if we could add that to the GMP plugin API directly.

I did this in D272613. Only doing the 5-frame limit wasn't enough as extreme settings to resolution, framerate and bitrate could easily trigger a deadlock situation anyway. Adding the callback to the GMP plugin API and implementing that in the OpenH264 plugin would be cleaner, but would take ~months to ship. This seems manageable for now.

If I limit to 5 frames in flight, we no longer have the leak, at least. But we better hope that OpenH264 doesn't decide to drop 5 frames in a row.

This wasn't enough on its own. But with the Skipped callback we can trivially bring the limit down to 1 frame, as it would behave if the API was sync.

Comment on attachment 9526721 [details]
Bug 1992567 - Retrofit a Skipped callback on top of GMP encoder API using input frame destroy calls. r?aosmond

Revision D272613 was moved to bug 1999970. Setting attachment 9526721 [details] to obsolete.

Attachment #9526721 - Attachment is obsolete: true

(In reply to Bulat Maksudov from comment #47)

I am using Intel i7-8550U. Could not find resolution in about:webrtc, but assuming it uses full display resolution, that would be 2560x1440.
The weird part here is that the sharing was working before about 1 month ago in same setup, so I assume something changed?

Would you mind running mozregression to figure it out? Could be a site issue, could be us, could also be an orthogonal change that happens to trigger this, but mozregression would let you figure that out.

Flags: needinfo?(b.maksudov)
Pushed by pehrsons@gmail.com: https://github.com/mozilla-firefox/firefox/commit/fa7d0e1257b3 https://hg.mozilla.org/integration/autoland/rev/42f68928a6c6 Enforce a hard limit of 1 frame in flight in WebRTC GMP encoder. r=webrtc-reviewers,bwc

https://hg.mozilla.org/mozilla-central/rev/42f68928a6c6

Status: ASSIGNED → RESOLVED
Closed: 11 months ago
status-firefox147: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 147 Branch
status-firefox146: affected → wontfix
Flags: needinfo?(crohmann)
Flags: needinfo?(b.maksudov)
Regressions: 2004850
QA Whiteboard: [qa-triage-done-c148/b147]

This avoids an ~unbounded memory leak when OpenH264 is not able to keep up with
encoding in real-time.

Also report frame drops from Encode() upwards.

Original Revision: https://phabricator.services.mozilla.com/D272451

Attachment #9532691 - Flags: approval-mozilla-esr140?
Attachment #9532691 - Flags: approval-mozilla-esr140?
Attachment #9532691 - Flags: approval-mozilla-esr140+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: