Repository navigation
Release the filter FBO when a filter is removed - #2210
Merged
Merged
Conversation
initFBOLink() gives every added filter a framebuffer, a depth renderbuffer and an RGBA texture the size of the stream. Nothing ever deletes them: release() of each filter only deletes its program (object filters also their content texture), and there is no glDeleteFramebuffers or glDeleteRenderbuffers in the library. So every removeFilter and clearFilters leaks one frame-size FBO until the EGL context is destroyed. Apps that change overlays during a stream run the GPU out of memory. MainRender now frees the FBO, the renderbuffer and the texture whenever it drops a filter, after the filter's own release(), on the GL thread that created them. The ids are reset to 0, so a second release does nothing and a filter added again gets new ones. setFilter keeps reusing the old filter's FBO for the new filter. The old filter gets a new RenderHandler before release(), so it no longer shares the ids with the filter that took its place. removeFilter(filter) now releases the filter only if it was in the list, so removing a filter twice can't delete ids that belong to something else. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner
|
Merged, thank you for the PR. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
initFBOLink()gives every filter added toMainRenderits own framebuffer, aDEPTH_COMPONENT16renderbuffer and an RGBA texture of the stream size (BaseRenderOffScreen.initFBO). Nothing deletes them. Each filter'srelease()deletes only its program (object filters also their content texture), and there is noglDeleteFramebuffersorglDeleteRenderbuffersanywhere in the library. So everyremoveFilterandclearFiltersleaks one frame-size FBO until the EGL context is destroyed.Nobody notices when filters are set once. An app that changes overlays during a stream keeps growing until the GPU runs out of memory. This may be what is behind #744 and #910.
Change
MainRenderfrees the framebuffer, the renderbuffer and the texture whenever it drops a filter (removeFilter,clearFilters,release). It does this after the filter's ownrelease(), on the GL thread that created them. The ids are reset to 0, so a second release does nothing and a filter added again gets new ones.setFilterstill reuses the old filter's FBO for the new filter. The old filter now gets a newRenderHandlerbefore itsrelease(), so the two filters no longer share the id arrays.removeFilter(filter)releases the filter only if it was in the list.Measured
Samsung Galaxy A06 (SM-A065F), our app on RootEncoder 2.8.0.
MainRender,RenderHandler,BaseRenderOffScreenandBaseFilterRenderare the same in 2.8.0, 2.8.1 and master. The test was a 30-minute stream to a local RTMP server, switching every 60 s between a scene with text, image and GIF overlays and an empty scene:dumpsys meminfowent from 146 to 564 MB in 16 switches, about 8 MB per overlay per switch.release(): PSS went from 381 to 358 MB, with a peak of 403 MB. Graphics went from 138 to 112 MB.These numbers come from that app-side equivalent. This patch itself compiles against master, but I haven't run it on a device yet.
🤖 Generated with Claude Code