VRAM (Dedicated GPU Memory) Leak

[nproctorGV]

Operating System Info

Windows 11

Other OS

No response

OBS Studio Version

31.0.0-rc1

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/YisuqH6bEI7DpLol

OBS Studio Crash Log URL

No response

Expected Behavior

Stable dedicated GPU memory

Current Behavior

Rapidly increasing dedicated GPU memory

Steps to Reproduce

1. Add a Browser 1920x1080 with URL https://www.testufo.com/framerates#count=1&background=none&pps=240
2. Output is 1920x1080/59.94
3. Watch Dedicated GPU Memory rapidly increase every seconds on Windows.

Anything else we should know?

No response

[RytoEX]

I am not observing any rapid increase (or any increase) in Dedicated GPU Memory consumption on Windows 11 with an Intel Arc A770M.

[Fenrirthviti]

Tested on an NVIDIA 4090 GPU on Windows 11, also did not observe any rapid GPU memory increase. Screenshot after letting the provided test URL run for 10~ minutes:

[nproctorGV]

Try adding the column to the details in the task manager:

Tested on an NVIDIA 4090 GPU on Windows 11, also did not observe any rapid GPU memory increase. Screenshot after letting the provided test URL run for 10~ minutes:

[Fenrirthviti]

Same session, barely 600mb allocated:

[RytoEX]

[nproctorGV]

https://www.loom.com/share/5d622bf8c2d14816912a799a24d028e6?sid=5f18ccaa-6d39-4992-ac62-6f3ac3f6ca29

[Fenrirthviti]

I don't think anyone doubts this is happening on your system, but it's not happening on ours, which means there's a piece of the puzzle missing. This could be a driver bug, for all we know, and if we can't reproduce the issue reliably, we can't really do anything about it.

[nproctorGV]

Understood. FYI I have reproduced the issue on 3 different NVIDIA GPUS: NVIDIA Quadro P2200 551.61 NVIDIA RTX A2000 553.35 NVIDIA Quadro RTX 4000 551.61

[pkviet]

could you disable hags and retest ? also what's your driver version ? We've noticed that your test GPUs differ from ours in that we have only consumer grade ones.

[nproctorGV]

I disabled hags on the NVIDIA RTX A2000 machine and it did not make any difference. There driver versions are: 553.35 - NVIDIA RTX A2000 551.61 - NVIDIA Quadro P2200 551.61 - NVIDIA Quadro RTX 4000

[pkviet]

I disabled hags on the NVIDIA RTX A2000 and it did not make any difference. There driver versions are: 553.35 - NVIDIA RTX A2000 551.61 - NVIDIA Quadro P2200 551.61 - NVIDIA Quadro RTX 4000

i didn't expect hags to make a difference but just in case... Could you update to last drivers ? 566.14

[nproctorGV]

553,35 is the latest from Nov 19. I tried the New Feature Branch 566.03 with the same results. I don't see a 566.14

[pkviet]

I tried to repro with a QUADRO RTX 4000 SFF ADA. It was running in a VM, so i'll put some cautionary note there. Anyway, no leak for me when running under the conditions given (testufo url at 1080p59); flat 400 MB dedicated RAM for 10 minutes. edit: driver version is the last one for quadro so 553.35

[Lordmau5]

Can confirm this is happening on my RTX 4060 (8GB VRAM), Studio Driver 566.14 Also happens with FPS set to 60 instead of 59.94.

In my main OBS instance (31 beta 3, latest TEB Beta build at the time of writing) it rose rather quickly, even surpassing what my GPU should be capable of (saw it at around 9,000,000K+). In a fresh 31rc1 instance with just the testufo page it is also rising, but slower. It started at around 70,000K after adding the browser source, and after around 10 minutes it sat at around 1,300,000K.

I've started with a fresh 31rc1 instance, clicked Cancel in the first time setup, then set the Canvas and Output resolution to 1440p, set the FPS to 60, added the browser source linked in the first post at 1920x1080 dimensions and waited

[Lordmau5]

Managed to reproduce on 2 other systems as well. My other PC with a 3090, 566.14 Game Ready Driver and my laptop with a 3070 laptop variant (didn't check the driver, but I think it was latest as well since I updated not too log ago)

The laptop ramped up really quickly - about 9,000,000K within 20 seconds.

[RytoEX]

Does anyone actually experience any detrimental behavior when this occurs?

[Lain-B]

Someone in the beta-testing channel claimed that doing a graphics flush command in the code made this not happen anymore, which leads me to suspect it's entirely possible that this is just some sort of driver memory management rather than an actual issue (much like how Windows will reserve a lot of your RAM and it'll look like RAM is in use when it's not), especially if it seems to have no actual effect on performance of other applications.

If someone does see significant and noticeable issues with other graphics programs or games on the system while OBS is running, please do note of it here like Ryan just said.

We didn't make any modifications to the graphics backend as far as I know (haven't really in years), so if there is an issue it could be something with CEF, but I would like people to specify whether this is actually affecting other programs on the computer.

Notably, in the development chat on the Discord, @Lordmau5 stated:

Also nice insight - seems that Firefox is having a similar issue :lordmaLUL: 
Had it open with some tabs for a while, and it's sitting at around 6.7GB dedicated VRAM now soooooooooo... haha

Which is interesting, and makes me wonder if there's something up with drivers there or some specific dependency that modern browsers share, but that's merely anecdotal so we probably shouldn't read too much into that one.

[Lain-B]

Forgive me accidental closing/reopening of the issue, hit the wrong button somehow or another.

[alinsavix]

Just as a minor datapoint, when I have a similar issue with dwm and firefox (VRAM grows under various conditions, but doesn't show up in the total VRAM used in hwinfo and such), it definitely does cause (somewhat difficult to quantify) performance issues. Not positive it's the same issue, of course, but based on various conversations it sure sounds similar.

[ZerionSeven]

I don't know if this is the same issue or a similar one, but after updating to OBS 31.0.0 today, whenever I change the visibility of any browser source, or change scenes with browser sources, total VRAM utilisation increases. This does not happen with other sources.

The utilisation does not show under any process, only in the total. It doesn't take much to exhaust my 16G of VRAM, especially when there's a game also running. When that happens, RAM utilisation starts increasing and performance of everything on the system quickly degrades. Exiting OBS reclaims all the VRAM and RAM.

I'm using: Windows 11 24H2 AMD RX 6900 XT on drivers 24.12.1

Edit: Disabling browser source hardware acceleration seems to avoid the problem. It does not move the problem to RAM.

[aethyrvt]

I appear to be experiencing the same issue, which eventually results in both browser sources and docks crashing and restarting. If OBS runs for long enough, this eventually leads to encoding errors and sometimes even crashing the graphics driver.

Like with what ZerionSeven experienced, the utilisation only shows up in total, and task manager doesn't report it as coming from OBS. However, when OBS either:

• Crashes from overutilising video memory
• Is closed manually

the memory allocation disappears, and the rest of the system returns to performing normally.

I'm running: Windows 11 24H2 AMD RX 6700XT on drivers 24.12.1

Edit: Again, appears to be an issue with hardware acceleration, symptoms disappear once disabled. Would have suggested a possible AMD driver issue however appears people running other cards experience it too

[KED88]

I think i'm having this issue. I just did a 3.5h stream and my vram was 100% by the end. After closing OBS my vram went down to 20%, with my game and everything else still running. Oddly enough, i added a browser source last night, and i dont think i was having this issue before that.

https://obsproject.com/logs/Lhr7FV8M6p8hHsDZ

[Mckids]

I finally solved this problem by disabling browser source hardware acceleration, an option in settings under the advanced tab near the bottom

[ev3rest]

Can confirm that turning Browser Hardware Acceleration fixes the issue. GPU: 9070XT OS: Windows 11 24H2 Driver Version: 25.6.1 OBS Version: 31.0.3, 31.1 Beta 1&2

[MaliMiau]

By making my own HTML files and testing some stuff, I found out that any kind of movement (canvas drawing, a video, a transition, an animation) fills the VRAM a little, and if it repeats it will eventually fill it completely. I don't know if this matters for actually resolving the problem, but at least knowing it may help someone looking for a workaround. If your web source has movement, then that is probably the cause.

Other than this, there are three fixes that I've tested that actually work:

• Disabling hardware acceleration for browser sources. (Although with the movement, instead of the VRAM filling up, it uses all of my CPU instead)
• Lowering the video FPS to 30 or less.
• Checking "Use custom frame rate" in the source and setting FPS to 30 or less.

[MaliMiau]

I tried updating to 31.1 Release Candidate 1 and it fixed the issue.

[spinalcord]

I stumbled over google to this issue. However I use Linux with the current OBS Flatpak 31.1.2. VRAM is filling up if I repeat the record and stop process. And It doesn't matter how much time I leave between this step. Solution is currently only to to restart OBS.

My VRAM Capacity 16311MiB. Initial Vram usage, with OBS running: 673MiB / 16311MiB

Record click: 1058MiB / 16311MiB Stop click: 855MiB / 16311MiB Record click: 1215MiB / 16311MiB Stop click: 1016MiB / 16311MiB Record click: 1358MiB / 16311MiB Stop click: 1166MiB / 16311MiB Record click: 1527MiB / 16311MiB Stop click: 1309MiB / 16311MiB ...

Nvidia 5060 ti

[Kobi-Blade]

I tried updating to 31.1 Release Candidate 1 and it fixed the issue.~

Versions 31.1.1 and 31.1.2 of OBS continue to exhibit the issue. OBS crashes with out of memory exception (taking along with it any GPU accelerated software and Games), consistent with reports from other users experiencing similar behavior.

This issue appears to be independent of GPU driver versions as well. I recently updated to 25.8.1 on an AMD Radeon RX 6950 XT, yet the problem persists.

The memory leak becomes increasingly evident during extended streams, where OBS gradually and continuously allocates VRAM over time without releasing it, ultimately leading to system instability and crashes with the dump,

FILE_IN_CAB:  obs-browser-page.exe.14164.dmp

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

CONTEXT:  (.ecxr)
rax=00207b011cd3a3f5 rbx=0000000000000000 rcx=000000b2c0cfe618
rdx=000000b2c0cfb250 rsi=000000b2c0cfb4d0 rdi=000000b2c0cfad00
rip=00007ff889035369 rsp=000000b2c0cfb4b0 rbp=0000000000000000
 r8=00003734004a5358  r9=0000373400723818 r10=00003734007b0838
r11=0000000000000000 r12=0000461004e04000 r13=000000b2c0cfb927
r14=0000000000280000 r15=0000000000280000
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000204
KERNELBASE!RaiseException+0x69:
00007ff8`89035369 0f1f440000      nop     dword ptr [rax+rax]
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ff889035369 (KERNELBASE!RaiseException+0x0000000000000069)
   ExceptionCode: e0000008
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 0000000000280000

PROCESS_NAME:  obs-browser-page.exe

ERROR_CODE: (NTSTATUS) 0xe0000008 - <Unable to get error code text>

EXCEPTION_CODE_STR:  e0000008

EXCEPTION_PARAMETER1:  0000000000280000

STACK_TEXT:  
000000b2`c0cfb4b0 00007ff8`203cdb29     : 00000000`00000007 000000b0`00000000 000000b0`00000000 000000b2`c0cfb6b7 : KERNELBASE!RaiseException+0x69
000000b2`c0cfb590 00007ff8`203cdb49     : 00000000`00000000 000000b2`c0cfb6c0 000000b0`00000000 000000b2`c0cfb6a1 : libcef!CrashForExceptionInNonABICompliantCodeRange+0x20fbec9
000000b2`c0cfb5c0 00007ff8`203cdb65     : 00000000`00000040 00007ff8`1b9b470a 00000000`00000017 00000000`0000000b : libcef!CrashForExceptionInNonABICompliantCodeRange+0x20fbee9
000000b2`c0cfb5f0 00007ff8`2097b611     : 00007ff8`26c8cf78 00007ff8`1b837470 00000000`00280000 00004610`04e04000 : libcef!CrashForExceptionInNonABICompliantCodeRange+0x20fbf05
000000b2`c0cfb620 00007ff8`2097b369     : aaaaaaaa`aaaaaa00 00000005`0001e000 aaaaaaaa`aaaaaa00 00207801`c0cfbee0 : libcef!CrashForExceptionInNonABICompliantCodeRange+0x26a99b1
000000b2`c0cfb660 00007ff8`203cd05d     : aa000000`000005af aaaaaaaa`aaaaaaaa 00007ff8`26e61b30 000000b2`c0cfbba0 : libcef!CrashForExceptionInNonABICompliantCodeRange+0x26a9709
000000b2`c0cfb710 00007ff8`203cd8f7     : 00000000`00280000 00007ff8`1b9416f8 aaaaaaaa`aaaaaa00 00004610`04e01020 : libcef!CrashForExceptionInNonABICompliantCodeRange+0x20fb3fd
000000b2`c0cfb790 00007ff8`1cb52b1b     : 00000000`00000005 00000780`00000000 aaaaaaaa`00000438 00000000`00000000 : libcef!CrashForExceptionInNonABICompliantCodeRange+0x20fbc97
000000b2`c0cfb7d0 00007ff8`1cb4fe02     : 000000c6`1928f7c4 00000000`00000000 00003734`00723818 00003734`007b0838 : libcef!GetHandleVerifier+0x1215a1b
000000b2`c0cfb8d0 00007ff8`1b654d62     : aaaaaaaa`aaaaaaaa 00007ff8`260d1b28 00000000`00000010 00000000`00000000 : libcef!GetHandleVerifier+0x1212d02
000000b2`c0cfb9d0 00007ff8`211edf13     : 000000b2`c0cfbac8 00007ff8`1cb3907d aaaaaaaa`aaaaaa00 aaaaaaaa`aaaaaa00 : libcef!cef_time_from_basetime+0xa2d022
000000b2`c0cfba10 00007ff8`211edac4     : aaaaaaaa`aaaaaaaa 00007ff8`1cb52fe9 00000000`00000000 000000b2`c0cfc098 : libcef!RelaunchChromeBrowserWithNewCommandLineIfNeeded+0x4e6963
000000b2`c0cfba50 00007ff8`1cbb68c3     : 0000522b`00000000 0000522b`008c98fd 00004610`004da0d8 00007ff8`1cb52c43 : libcef!RelaunchChromeBrowserWithNewCommandLineIfNeeded+0x4e6514
000000b2`c0cfbb20 00007ff8`1cc8482d     : 00000000`00000010 00007ff8`1c606cbc aa000000`00000000 00000000`00612963 : libcef!GetHandleVerifier+0x12797c3
000000b2`c0cfbb80 00007ff8`1c657195     : aaaaaaaa`aaaaaa01 00003734`00207880 00003734`006cd998 00007ff8`1cb52fe9 : libcef!GetHandleVerifier+0x134772d
000000b2`c0cfbbb0 00007ff8`1c61b89e     : 00003734`00611a70 00000000`d507426e 00000000`3541d09b 000000c6`1928f464 : libcef!GetHandleVerifier+0xd1a095
000000b2`c0cfbc30 00007ff8`1c4e160e     : 00004610`00507310 00007ff8`1c55e8ee 00004610`005c4000 00004610`005c4000 : libcef!GetHandleVerifier+0xcde79e
000000b2`c0cfc2e0 00007ff8`1aff7229     : 00000000`00000000 000000c6`19288a44 00004610`005072f0 00007ff8`1c5646e9 : libcef!GetHandleVerifier+0xba450e
000000b2`c0cfc630 00007ff8`1c68c202     : 000000c6`19288904 00000000`00000008 00000000`00000000 00000000`00000014 : libcef!cef_time_from_basetime+0x3cf4e9
000000b2`c0cfc700 00007ff7`9feab9ba     : 00004610`00486a80 0000522b`00a00000 00004610`00568980 00007ff8`1c52e2bd : libcef!GetHandleVerifier+0xd4f102
000000b2`c0cfc780 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff7`9feab9ba


STACK_COMMAND: ~0s; .ecxr ; kb

SYMBOL_NAME:  libcef+5b3db29

MODULE_NAME: libcef

IMAGE_NAME:  libcef.dll

FAILURE_BUCKET_ID:  APPLICATION_FAULT_e0000008_libcef.dll!Unknown

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  127.145.7.0

FAILURE_ID_HASH:  {56f16d53-c57a-bf44-d7f6-f21520b427e0}

Followup:     MachineOwner
---------