Recover appsrc from stranded flushing state instead of failing the egress - #1312
Merged
Conversation
…ress We still see persistent FlowFlushing failures after #1293/#1305, including on file-only egress, which rules out the RTMP sink path as the only trigger. The pipeline dump from that failure shows the exact stranded state: the appsrc reports PLAYING with clean pad flags, but its streaming task is paused and its internal flushing flag is stuck, so every PushBuffer returns FlowFlushing from the very first packet until the writer gives up. Trying to fix the persistent flow flushing with significantly lighter logic than before - basically by sending flush start / stop events which should clear the flushing state and restart task allowing data to flow
Contributor
|
AV-sync stats summary: view in run #30280614030 |
boks1971
approved these changes
Jul 27, 2026
| if !w.src.SendEvent(gst.NewFlushStopEvent(false)) { | ||
| w.logger.Warnw("failed to send recovery flush stop event", nil) | ||
| } | ||
| w.logger.Infow("FlowFlushing recovery successful") |
Contributor
There was a problem hiding this comment.
is this successful even if flush stop send fails?
Contributor
Author
There was a problem hiding this comment.
ugh - no - it could be misleading - will update it - good catch - thanks!
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.
We still see persistent FlowFlushing failures after #1293/#1305, including on file-only egress, which rules out the RTMP sink path as the only trigger. The pipeline dump from that failure shows the exact stranded state: the appsrc reports PLAYING with clean pad flags, but its streaming task is paused and its internal flushing flag is stuck, so every PushBuffer returns FlowFlushing from the very first packet until the writer gives up.
Trying to fix the persistent flow flushing with significantly lighter logic than before - basically by sending flush start / stop events which should clear the flushing state and restart task allowing data to flow