GNOME Bugzilla – Bug 767666
splitmuxsink: infinite change_state loop
Last modified: 2018-11-03 15:09:55 UTC
I override GstElementClass::change_state() in the parent GstBin containing splitmuxsink. Since 1.8.2 (was not in 1.8.1) I see that it's being called in loop with transition PAUSED to PLAYING. Reverting a97face and f2872ee fix the problem.
What does your new change_state function look like? Does it also happen if you don't override it?
It is a trivial print debug and chain up. I use GST_STATE_TRANSITION_CURRENT/NEXT to know it's a PAUSED->PLAYING transition.
So it also happens if you don't override it? Do you have a way to reproduce the problem?
(In reply to Tim-Philipp Müller from comment #3) > So it also happens if you don't override it? Yes, but you won't notice it actually happens. As far as I can tell, everything still works perfectly. If I hadn't that debug print I wouldn't have noticed that regression. > Do you have a way to reproduce the problem? I haven't tried to write a test case yet, will try to make one. Worth noting that in my case splitmuxsink is wrapped into a bin that has async-handling = TRUE.
I don't understand your bug description. How can you have an infinite looping state change function and not see any outward signs. You'd think it'd crash or use 100% CPU or something.
Setting NEEDINFO. I think we need a way to reproduce it or at least a debug log.
Also marking as blocker since it sounds like it's a regression from 1.8.1 to 1.8.2.
(In reply to Jan Schmidt from comment #5) > I don't understand your bug description. How can you have an infinite > looping state change function and not see any outward signs. You'd think > it'd crash or use 100% CPU or something. State transition is made from another thread, it is gst_bin_continue_func() that runs in loop, if I understand correctly. So that's not preventing the rest of the pipeline to work. This clearly needs a test case, I'll try to find time to write one.
This seems to be a fundamental problem in core with bins that have async-handling=TRUE because they don't send async-start, but return ASYNC from the state change function. The pipeline just tries to continue state constantly because it has no async-start message stored from the child. For now, I've reverted the commit which switched from using some internal logic to using the bin's async-handling. commit 5a71334fb0be6f1bd4c15815c7dad3567306d47b Author: Jan Schmidt <jan@centricular.com> Date: Mon Aug 8 02:53:48 2016 +1000 Revert "splitmuxsink: Use GstBin async-handling instead of our own." This reverts commit fa008f271a52f82dededc28bd81b020ca7939b47. async-handling in GstBin causes the pipeline to spin at 100% CPU as the top-level pipeline tries to change that state to PLAYING constantly. This is a workaround for a core problem, essentially, but an improvement in this case for now.
No longer a blocker.
(In reply to Jan Schmidt from comment #9) > This seems to be a fundamental problem in core with bins that have > async-handling=TRUE because they don't send async-start, but return ASYNC > from the state change function. The pipeline just tries to continue state > constantly because it has no async-start message stored from the child. So that should happen with other elements than splitmuxsink? That sounds more blocker than ever, no?
No, a blocker is something we should hold the release for. Fundamental problems that have existed for who-knows-how-long without causing widespread trouble generally aren't, even if they *do* need fixing.
ok, didn't know that has always been like that. Surely there is a bug opened for it already then? Should we close this one as dup ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/280.