Merged
Conversation
Continuned hunt for the source of the issue where a track packets could end up not pushed to the pipeline at all due to a flushing error - indicating that either streaming thread from appsrc hit a pad which isn't activated or it was stopped for some reason. Since the state propagation inside a bin for upword state transitions (NULL->READY->PAUSED->PLAYING) follows sink-source elements order - when the app source hits PLAYING state, all other elements should be in that state as well which likely means it wasn't hitting a deactivated pad that was issue here but rather streaming thread stopping. It could stop on downwords state transition PAUSED->READY - so one plausible theory is that it was somehow caused by 2 concurrent state transition processes - one global pipeline transition to PLAYING operation and an explict operation to set the state to PLAYING after linking the source. One could be driving state to PLAYING much faster and when other starts - it might want to go through the same sequence of state - basically regressing it and maybe stopping the streaming thread. Adding logs to test that theory - if this is the case - we will see states going up and down.
boks1971
approved these changes
Feb 28, 2026
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.
Continuing the hunt for the source of the issue where a track packets could end up not pushed to the pipeline at all due to a flushing error - indicating that either streaming thread from appsrc hit a pad which isn't activated or it was stopped for some reason. Since the state propagation inside a bin for upward state transitions (NULL->READY->PAUSED->PLAYING) follows sink-source elements order - when the app source hits PLAYING state, all other elements in the src bin should be in that state as well which likely means it wasn't hitting a deactivated pad that was issue here but rather streaming thread stopping. It could stop on downward state transition PAUSED->READY - so one plausible theory is that it was somehow caused by 2 concurrent state transition processes - one global pipeline transition to PLAYING operation and an explicit operation to set the its state to PLAYING after linking it to the pipeline (inside bin.go). One could be driving state to PLAYING much faster and when other starts - it might want to go through the same sequence of state - basically regressing it and maybe stopping the streaming thread. Adding logs to test that theory - if this is the case - we will see states going up and down.