[BUG] Plugin uses insane amount of memory when using css animations

Jncls commented

2020-04-18 02:50:26 -05:00

(Migrated from github.com)

Platform

Operating system and version: MacOS 10.14.4
OBS Studio version: 25.0.7

Expected Behavior

I'm using the browser plugin to show interactive contents during my streams. Until last week everything worked like charm but at this time I made a new site to show a little blinking dot in the top right corner by using html and css animations. While not streaming/ recording OBS is using ~250 MB memory on my machine. My expectation is that it should increase a bit but not more than a few MB.

Current Behavior

When using the site with the css animation in a scene the memory consumption raises incrementally to several hundred megabytes. Sometimes (after switching scenes back and forth) it goes up to several gigabytes until the OS warning is shown - after the warning MacOS kills the entire OBS instance to protect the system. Also CPU consumption is going through the roof. The interesting thing is that memory usage of "obs-browser-page" looks quite normal but memory of the main OBS process is taking all the memory.

Steps to Reproduce

Use the html that is attached below as an overlay in a scene and watch MacOS's activity monitor.

Additional information

HTML to reproduce the behavior:

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">

    <style>
        .blink {
            animation: blinker 1.2s cubic-bezier(.5, 0, 1, 1) infinite alternate;            
        }

        @keyframes blinker {
            100% {
                opacity: 0;
            }
        }

        .dot {
            height: 18px;
            width: 18px;
            background-color: #ed553b;
            border-radius: 50%;
            display: inline-block;
            vertical-align: middle;            
        }

        .top-right {
            line-height: 40px;
            position: absolute;
            right: 20px;
            top: 10px;
        }

        .font {
            font-family: Arial, Helvetica, sans-serif;
            font-size: 20px;
            font-weight: bold;
            vertical-align: middle;
            padding-left: 4px;
        }
    </style>

</head>

<body>
    <div class="top-right">
        <span class="dot blink"></span> <span class="font">LIVE</span>
    </div>
</body>

</html>

## Platform Operating system and version: MacOS 10.14.4 OBS Studio version: 25.0.7 ## Expected Behavior I'm using the browser plugin to show interactive contents during my streams. Until last week everything worked like charm but at this time I made a new site to show a little blinking dot in the top right corner by using html and css animations. While not streaming/ recording OBS is using ~250 MB memory on my machine. My expectation is that it should increase a bit but not more than a few MB. ## Current Behavior When using the site with the css animation in a scene the memory consumption raises incrementally to several hundred megabytes. Sometimes (after switching scenes back and forth) it goes up to several gigabytes until the OS warning is shown - after the warning MacOS kills the entire OBS instance to protect the system. Also CPU consumption is going through the roof. The interesting thing is that memory usage of "obs-browser-page" looks quite normal but memory of the main OBS process is taking all the memory. ## Steps to Reproduce Use the html that is attached below as an overlay in a scene and watch MacOS's activity monitor. ## Additional information HTML to reproduce the behavior: ```html <!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <style> .blink { animation: blinker 1.2s cubic-bezier(.5, 0, 1, 1) infinite alternate; } @keyframes blinker { 100% { opacity: 0; } } .dot { height: 18px; width: 18px; background-color: #ed553b; border-radius: 50%; display: inline-block; vertical-align: middle; } .top-right { line-height: 40px; position: absolute; right: 20px; top: 10px; } .font { font-family: Arial, Helvetica, sans-serif; font-size: 20px; font-weight: bold; vertical-align: middle; padding-left: 4px; } </style> </head> <body> <div class="top-right"> <span class="dot blink"></span> <span class="font">LIVE</span> </div> </body> </html> ```

👍 3

njutn95 commented

2020-04-21 16:10:07 -05:00

(Migrated from github.com)

Similar issue on my end as well, except it's a windows machine and it's not hurting obs process but obs-browser-page. I've opened #223 to keep things separate in case they're different problems.

Similar issue on my end as well, except it's a windows machine and it's not hurting obs process but `obs-browser-page`. I've opened #223 to keep things separate in case they're different problems.

bStyler commented

2020-05-06 09:09:31 -05:00

(Migrated from github.com)

This issue seems to still exist in OBS Studio version 25.0.8 on PC / Windows

bardiir commented

2020-12-31 06:22:02 -06:00

(Migrated from github.com)

I can confirm this on OBS 26.1 on Big Sur M1 - If there are CSS Animations present on the page code in any form or function the OBS browser does start leaking memory as long as it is visible until the memory depletion triggers and kills OBS.

It's allocating around 10MB/sec per open browser instance, so quite a significant memory leak. I had OBS reach 64GB of memory usage previously.

If the page does not contain any CSS animation code - it will not leak. Even on BigSur which currently is plagued by a lot of other issues anyway.

If there is any experiment/testing you might want checked, let me know and I'll gladly help to trace this :)

I can confirm this on OBS 26.1 on Big Sur M1 - If there are CSS Animations present on the page code in any form or function the OBS browser does start leaking memory as long as it is visible until the memory depletion triggers and kills OBS. It's allocating around 10MB/sec per open browser instance, so quite a significant memory leak. I had OBS reach 64GB of memory usage previously. If the page does not contain any CSS animation code - it will not leak. Even on BigSur which currently is plagued by a lot of other issues anyway. If there is any experiment/testing you might want checked, let me know and I'll gladly help to trace this :)

njutn95 commented

2020-12-31 11:32:10 -06:00

(Migrated from github.com)

@bardiir Out of curiousity, how long were you running OBS when you reached 64GB memory usage? Is it exponential or linear grow? And also, which process is it actually - obs or obs-browser-page? Might be useful information in case this gains any attention 🙂

@bardiir Out of curiousity, how long were you running OBS when you reached 64GB memory usage? Is it exponential or linear grow? And also, which process is it actually - `obs` or `obs-browser-page`? Might be useful information in case this gains any attention :slightly_smiling_face:

bardiir commented

2020-12-31 11:58:32 -06:00

(Migrated from github.com)

@njutn95 It was running quite a while - it was open in the background and started swapping there - system was surprisingly responsive until it ran out of memory. It's linear grow, it grows faster the more browser instances you got visible. But the growth per browser seems to be static and very linear over time (I would guess there are rendered frames or something like that leaking into the memory).

The memory is leaking into the OBS process - not the browser page itself. After running for a few minutes (OBS base with no browsers open uses around 700-800MB memory for me):
Bildschirmfoto 2020-12-31 um 18 57 02

@njutn95 It was running quite a while - it was open in the background and started swapping there - system was surprisingly responsive until it ran out of memory. It's linear grow, it grows faster the more browser instances you got visible. But the growth per browser seems to be static and very linear over time (I would guess there are rendered frames or something like that leaking into the memory). The memory is leaking into the OBS process - not the browser page itself. After running for a few minutes (OBS base with no browsers open uses around 700-800MB memory for me): <img width="887" alt="Bildschirmfoto 2020-12-31 um 18 57 02" src="https://user-images.githubusercontent.com/11957301/103420944-12f49e00-4b9a-11eb-9856-d7e4ed64be0f.png">

👍 1

WizardCM commented

2021-01-31 05:05:54 -06:00

(Migrated from github.com)

Hi there, is this still an issue in OBS 26.1.2? We overhauled how the browser backend is run and updated the browser library. Let us know!

bardiir commented

2021-01-31 05:08:20 -06:00

(Migrated from github.com)

@WizardCM the memory leak I experienced is fixed in 26.1.2

WizardCM commented

2021-01-31 05:11:48 -06:00

(Migrated from github.com)

@bardiir As a final test with 26.1.2, could you go to Settings -> Advanced and at the bottom disable Hardware Acceleration, and see if the issue comes back? If the issue returns, it'll confirm your theory about it happening during the non-accellerated render function.

Once you've verified, you can turn Hardware Acceleration back on.

@bardiir As a final test with 26.1.2, could you go to Settings -> Advanced and at the bottom disable Hardware Acceleration, and see if the issue comes back? If the issue returns, it'll confirm your theory about it happening during the non-accellerated render function. Once you've verified, you can turn Hardware Acceleration back on.

bStyler commented

2021-01-31 06:04:31 -06:00

(Migrated from github.com)

@WizardCM I'd love to test the same on Windows, may I know what's the ETA for 26.1.2 on Windows?

bardiir commented

2021-01-31 06:13:00 -06:00

(Migrated from github.com)

@WizardCM I can confirm - disabling hardware acceleration does enable a memory leak, OBS is slowly creeping up again, I think it's slower than before but that is just a gut feeling no measurement. It's definitely leaking without the hardware acceleration. OBS usually sits around 400-500MB for me, now it is already at 1.5GB after around an hour.

WizardCM commented

2021-01-31 06:44:12 -06:00

(Migrated from github.com)

@WizardCM I'd love to test the same on Windows, may I know what's the ETA for 26.1.2 on Windows?

Windows has had hardware acceleration on by default for at least a year and a half now. If the issue exists on Windows, disabling hardware acceleration the same way n Settings -> Advanced would be a way to reproduce it.

The browser update in 26.1.2 is purely a change on the macOS version, as it previously didn't support hardware acceleration. To update the browser dependency on Windows, it requires more work. It's on the to do list but nobody with the required skillset has had time to dive into it.

@WizardCM I can confirm - disabling hardware acceleration does enable a memory leak,

OK, good to know. That definitely shortens the list of potential causes.

In terms of next steps, I'll coordinate internally (and verify myself) as to which functions run when hardware acceleration is on vs when it's off. As the memory leak occurs in the OBS process and not the CEF process, this means it could be a larger issue and not limited to the browser source.

I'll post an update as soon as I know more.

> @WizardCM I'd love to test the same on Windows, may I know what's the ETA for 26.1.2 on Windows? Windows has had hardware acceleration on by default for at least a year and a half now. If the issue exists on Windows, disabling hardware acceleration the same way n Settings -> Advanced would be a way to reproduce it. The browser update in 26.1.2 is purely a change on the macOS version, as it previously didn't support hardware acceleration. To update the browser dependency on Windows, it requires more work. It's on the to do list but nobody with the required skillset has had time to dive into it. > @WizardCM I can confirm - disabling hardware acceleration does enable a memory leak, OK, good to know. That definitely shortens the list of potential causes. In terms of next steps, I'll coordinate internally (and verify myself) as to which functions run when hardware acceleration is on vs when it's off. As the memory leak occurs in the OBS process and not the CEF process, this means it could be a larger issue and not limited to the browser source. I'll post an update as soon as I know more.

❤️ 3

bStyler commented

2021-02-07 11:50:37 -06:00

(Migrated from github.com)

Windows has had hardware acceleration on by default for at least a year and a half now. If the issue exists on Windows, disabling hardware acceleration the same way n Settings -> Advanced would be a way to reproduce it.

The browser update in 26.1.2 is purely a change on the macOS version, as it previously didn't support hardware acceleration. To update the browser dependency on Windows, it requires more work. It's on the to do list but nobody with the required skillset has had time to dive into it.

Thank you for your efforts @WizardCM -- anxious to hear your updates on Windows.

> Windows has had hardware acceleration on by default for at least a year and a half now. If the issue exists on Windows, disabling hardware acceleration the same way n Settings -> Advanced would be a way to reproduce it. > The browser update in 26.1.2 is purely a change on the macOS version, as it previously didn't support hardware acceleration. To update the browser dependency on Windows, it requires more work. It's on the to do list but nobody with the required skillset has had time to dive into it. Thank you for your efforts @WizardCM -- anxious to hear your updates on Windows.

PatTheMav commented

2021-02-27 09:51:14 -06:00

(Migrated from github.com)

I just finished a profiling run of our current master branch with CEF 4183 and disabled hardware acceleration, logging memory allocation activity over more than an hour and was not able to observe increased memory usage.

Memory usage breakdown

~35% by IOSurfaceClientCreate (which might warrant additional research as I'm not aware of IOSurfaces being used outside of Syphon and CEF with hardware acceleration
~28% by CEF itself
~18% by OBS' graphics thread implementation
~14% by - what looks like - CEF's rendering helper

So about 42% of memory usage is down to CEF, which should come as no surprise - Chromium is not exactly known for being easy on memory.

Persistent usage was more or less stable, whereas total virtual memory usage was ballooning by the second, but that's to be expected with web-based animations (and not an issue as the memory is freed and reclaimed automatically anyway).

I found some leaks but none where related to the browser source (and total impact was a few bytes).

Total memory usage after about 2 hours of just running the CSS animation: ~239MB.

So this issue is either not present in recent code anymore or there are other factors involved. @bardiir as you tested with 26.1.2, can you give precise "steps to reproduce"?

I just finished a profiling run of our current master branch with CEF 4183 and disabled hardware acceleration, logging memory allocation activity over more than an hour and was not able to observe increased memory usage. <details> <summary>Memory usage breakdown</summary> <br /> * ~35% by IOSurfaceClientCreate (which might warrant additional research as I'm not aware of IOSurfaces being used outside of Syphon and CEF _with_ hardware acceleration * ~28% by CEF itself * ~18% by OBS' graphics thread implementation * ~14% by - what looks like - CEF's rendering helper So about 42% of memory usage is down to CEF, which should come as no surprise - Chromium is not exactly known for being easy on memory. </details> Persistent usage was more or less stable, whereas total virtual memory usage was ballooning by the second, but that's to be expected with web-based animations (and not an issue as the memory is freed and reclaimed automatically anyway). I found some leaks but none where related to the browser source (and total impact was a few bytes). Total memory usage after about 2 hours of just running the CSS animation: ~239MB. So this issue is either not present in recent code anymore _or_ there are other factors involved. @bardiir as you tested with 26.1.2, can you give precise "steps to reproduce"?

RytoEX commented

2022-01-12 16:06:53 -06:00

(Migrated from github.com)

Per @PatTheMav 's comment above, we are unable to reproduce this and do not believe this issue to be present in obs-browser anymore, so we will be closing this Issue. If someone can provide steps-to-reproduce in the current stable or beta release of OBS Studio (at time of writing, stable is 27.1.3 and beta is 27.2.0), then we can reopen this and investigate further.

Per @PatTheMav 's [comment above](https://github.com/obsproject/obs-browser/issues/221#issuecomment-787093149), we are unable to reproduce this and do not believe this issue to be present in obs-browser anymore, so we will be closing this Issue. If someone can provide steps-to-reproduce in the current stable or beta release of OBS Studio (at time of writing, stable is 27.1.3 and beta is 27.2.0), then we can reopen this and investigate further.

👍 1

Rows
Columns

[BUG] Plugin uses insane amount of memory when using css animations #221

Platform

Expected Behavior

Current Behavior

Steps to Reproduce

Additional information