Add a toggle to captures to FULLY disable them when hidden

[TheGeekno72]

Hi,

This is a feature request post; if you want to skip the reason behind this post, go to the bottom to read my suggestion. (I genuinely think this to be a good QoL feature for OBS)

I have a problem : I use a "capture scene" with one capture per game I want to put on canvas. The way I make use of that is by designating "capture specific window" and have it look for the running executable, it's useful because I can customize whatever I want about the sources. No, I will not use the hotkey mechanic, hard set captures are the way I want to do things.

Now, I have all captures hidden at all times, if I want to show Game A, Game B, Game C, ..., Game Z, I have streamer.bot telling OBS to hide all sources and only set "visibility: show" on the one source I want to get at the press of a button. The problem is, the list grew and up to a point, that didn't cause any issues. Until it did. I've been on a wild, WILD goose chase, trying to find why the hell was my RAM maxxed out when normal usage was barely around 30%.

Turns out, for some reason, when streaming with OBS, something causes a RAM leak and it's undetectable. I'll refer you to this post I've made on AMD's support forums (as well as every single one of my interactions in both the OBS and AMD Discords for the duration of this mess) resuming all the details of everything I tried as troubleshooting for over TWO WHOLE MONTHS up until it stopped for some reason (I changed absolutely nothing, I even paused Windows updates to make sure) and it appeared again today, on a fresh reboot, on a stream start without any game running

I had someone look over my logs, told me that there was a gigantic amount of attempt from all the hidden sources to fetch captures from all the executables they were pointed at (of course all failed as none were running), seems pretty obvious now what is causing my RAM to skyrocket beyond capacity and slowing the whole machine down to a crawl once it starts swapping on the OS drive.

WHAT I AM ASKING FOR :
Local media sources have a "Close file when inactive" option and a "show nothing when playback ends" option. Why not make something similar for captures ? a checkbox to forcefully disable the capture process when hidden, only resume activity when shown on canvas.

I will be more than happy to provide every single one of the piece of information I have retained about this now 10 weeks running problem if you wish to see it for yourself, just send me a message (I can't be bothered to pollute this post with a shitload of screenshots and log links here)

[Fenrirthviti]

This sounds more likely to be a feature request, and we are not currently accepting feature requests on GitHub Discussions. Make sure you read any pinned posts on discussion boards before opening a new discussion. Please use our Ideas Page to submit your idea.

Thank you!

[Erasmusdev]

This sounds more likely to be a feature request, and we are not currently accepting feature requests on GitHub Discussions. Make sure you read any pinned posts on discussion boards before opening a new discussion. Please use our Ideas Page to submit your idea.

Thank you!

Hello, I am the person who went over his code, and no, it's not a feature.
It's OBS not being able to gracefully handle the repeated initialization failures of numerous inactive Application Audio Capture (WASAPI) sources, leading to a massive memory/resource bloat within the OBS application itself.

Here is the exact pattern from his log that demonstrates the issue:

The client has over 20 separate Application Audio Capture (AAC) sources (e.g., for different games) added to their scene collection. When OBS starts, and these target applications (the games) are not running, the log shows a repetitive cycle of failed initialization for each source.

For every inactive AAC source, you see this pattern:

$$[WASAPISource::TryInitialize]:[[VIRTUAL_AUDIO_DEVICE_PROCESS_LOOPBACK]] \textbf{Failed to find window}$$ $$WASAPI: Device '' \textbf{failed to start} (source: [Source Name])$$

This pattern repeats over 20 times in a single second. The current implementation appears to:

1. Allocate resources: to prepare for the WASAPI capture.
2. Fail to initialize: because the target application's window is not present.
3. Fail to fully or properly deallocate/cleanup the resources associated with that failed attempt.

This constant, repeated failed initialization and subsequent lack of resource cleanup creates a "pseudo-memory leak" or resource bloat within the OBS process for every single inactive audio source, resulting in the OBS application memory usage being unnecessarily high at idle.

This is a bug in how OBS handles the cleanup of failed WASAPI initializations for the Application Audio Capture feature, not a request for a new feature. The user is simply expecting stable, non-bloated memory usage when an existing feature (AAC) is present but inactive.

[Fenrirthviti]

If this is a bug, then it should be reported as an github issue as a bug, not as a discussion post.