Large memory leak with RTMP source and dest YouTube

[ethomas997]

Operating System Info

Other

Other OS

Linux Mint 21

OBS Studio Version

Other

OBS Studio Version (Other)

Master_Sep_12_2022 + PR #7358

OBS Studio Log URL

https://obsproject.com/logs/bG01PvqZMrsZrH6K

OBS Studio Crash Log URL

No response

Expected Behavior

Stable memory consumption

Current Behavior

Over about 20 hours memory usage went from 100MB to 900MB. Input was RTMP stream, output was to YouTube (livestream), and recording to files (split every 24 hours).

See here for Heaptrack file (550MB): https://www.etheli.com/d/obs/heaptrack.obs.1330493.zst

Here is consumed-memory graph from that Heaptrack file

Steps to Reproduce

Run OBS as per above

Anything else we should know?

I was running a build I compiled from GitHub source 'master' as of Sep_12_2022 with PR #7358 applied. I've seen the same behavior when running release version 28.0.1

[tt2468]

Does reloading the media source or deleting it and recreating it have any affect on the memory usage?

[ethomas997]

I tried deleting and recreating the Media-RTMP source, usage stayed about the same. Stopping streaming/recording did not reduce memory usage.

[tt2468]

Do you have any data on isolated streaming or playback?

[ethomas997]

@tt2468 No. Is there something specific you'd like me to try?

[tt2468]

Well mainly just isolating whether it's the streaming that's causing the leak, the RTMP playback, or even something else. I'm working on opening your heaptrack file but the version from APT is incompatible and I've got to build it from source.

[tt2468]

So I got the heaptrack file up. It is definitely coming from the media source. Are you sure that reloading or recreating the source doesn't have any affect? You could possibly recreate the source a few hours into a test, and see if the memory growth flatlines for a while (in case somehow heaptrack isn't seeing the memory as freed, but the system is).

[tt2468]

I dug a bit and found the youtube stream you have. Looks like it's a feed coming from a security camera. Perhaps there's some sidechannel data that isn't commonly present in other streams. Would you be able to capture maybe an hour or two of the raw RTMP stream using rtmpdump? Theoretically that should allow me to reproduce on my end and debug further.

[ethomas997]

The originating source feed is from a remote miniPC running OBS Studio (v27.1.3), and the feed goes through a local server (nginx). I have a second (local) miniPC running OBS Studio that receives the feed and relays it out to YouTube (and that's the one with the memory-leak issue). If you create a media source with the RTMP address you should be able to duplicate the setup, see here for the address: https://www.etheli.com/d/obs/feedaddr.txt

Stopping and starting streaming (and recording) may be part of this. I deleted and restored the RTMP source setup in OBS Studio and started it up again, and over about 5 hours the memory seemed steady at around 165MB. I stopped and restarted streaming, and after that the memory went up to 187MB. I'll have to let it run a awhile to see if its memory footprint is really increasing or not.

[ethomas997]

Some new results: A did a test with streaming/recording not active, just the RTMP input source running, and still saw the leak:

Here is the log file for that run: https://obsproject.com/logs/b4VdHso-NIciKz4B Here is the heaptrack file (256MB): http://www.etheli.com/d/obs/heaptrack.obs.1592090.zst

Also, when running a similar setup with OBS Studio v27.2.4 I am seeing a similar memory leak, so this looks to be a long-standing issue with RTMP source.

[ghost]

The memory leak is because of:

[RytoEX]

It seems that the RTMP feed went down and we never got a chance to run an rtmpdump on it to capture data. As I understand it, either we need that original feed or we need this to be reproducible independent of that specific feed.

[ethomas997]

It seems that the RTMP feed went down and we never got a chance to run an rtmpdump on it to capture data. As I understand it, either we need that original feed or we need this to be reproducible independent of that specific feed.

The issue should be reproduce-able with any RTMP feed. I restored this link with the address so if you want you can use my feed: https://www.etheli.com/d/obs/feedaddr.txt

[gegoxaren]

I am experiencing the same behaviour with the flatpak version (29.0.1).

Streaming seems to do something bad. I can stream for about an hour and a half to two hours before all my 16 GiB of memory and 1 GiB swap is consumed, and the computer grinds to a halt (often without warning).

[RytoEX]

I am experiencing the same behaviour with the flatpak version (29.0.1).

Streaming seems to do something bad. I can stream for about an hour and a half to two hours before all my 16 GiB of memory and 1 GiB swap is consumed, and the computer grinds to a halt (often without warning).

Per this comment, this issue does not require streaming. It is about a possible memory leak in the Media Source.

[gegoxaren]

I am experiencing the same behaviour with the flatpak version (29.0.1). Streaming seems to do something bad. I can stream for about an hour and a half to two hours before all my 16 GiB of memory and 1 GiB swap is consumed, and the computer grinds to a halt (often without warning).

Per this comment, this issue does not require streaming. It is about a possible memory leak in the Media Source.

That is odd, as I'm pretty sure I don't use GStreamer Media Source.

[RytoEX]

I am experiencing the same behaviour with the flatpak version (29.0.1). Streaming seems to do something bad. I can stream for about an hour and a half to two hours before all my 16 GiB of memory and 1 GiB swap is consumed, and the computer grinds to a halt (often without warning).

Per this comment, this issue does not require streaming. It is about a possible memory leak in the Media Source.

That is odd, as I'm pretty sure I don't use GStreamer Media Source.

OBS' built-in Media Source does not use GStreamer.