feat(rtsp): fix file descriptor exhaustion and memory fragmentation #373
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, a new buffer pool was allocated for every received frame-sized package. This led to several critical issues: - Excessive memory consumption: H264 frames have large variations in size, causing significant memory usage over time. - File descriptor leaks: Each invocation of `gstreamer::BufferPool::new()` created a new socketpair, resulting in a steady increase in open file descriptors. This can be observed with: watch -n1 "ls -l /proc/<PID>/fd | wc -l" Over time, this would exhaust available file descriptors. - Application instability: On devices such as the Lumus cam, memory usage would continuously rise (over 7-8GiB after 5 hours), eventually leading to a crash. This commit resolves these issues by reusing buffer pools where possible and preventing unnecessary allocation of resources. This allocates a little bit too much memory for the frames, as it takes the next power of two for the buffer, but its worth it to stabilize the application Tested-by: Wadim Mueller <[email protected]>
This was referenced Aug 13, 2025
Open
RealZ9R
approved these changes
Sep 28, 2025
|
Seems like even the max buffer isnt large enough for some 4K cameras, as it filled instantly and still was unable to stream. I have 16 of them though, so maybe my use-case is an outlier. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, a new buffer pool was allocated for every received frame-sized package. This led to several critical issues:
Excessive memory consumption: H264 frames have large variations in size, causing significant memory usage over time.
File descriptor leaks: Each invocation of
gstreamer::BufferPool::new()created a new socketpair, resulting in a steady increase in open file descriptors. This can be observed with:watch -n1 "ls -l /proc/PID/fd | wc -l"
Over time, this would exhaust available file descriptors.
Application instability: On devices such as the Lumus cam, memory usage would continuously rise (over 7-8GiB after 5 hours), eventually leading to a crash.
This commit resolves these issues by reusing buffer pools where possible and preventing unnecessary allocation of resources. This allocates a little bit too much memory for the frames, as it takes the next power of two for the buffer, but its worth it to stabilize the application
Tested-by: Wadim Mueller [email protected]