GNOME Bugzilla – Bug 708789
playbin: make sure elements are in null before disposing
Last modified: 2013-10-04 11:02:00 UTC
It is quite common to see messages of elements being disposed in READY. Specially happens when pipelines fail when prerolling. I tracked those down to a particular unref in the group deactivation. Putting the patch here for review in case there is a reason not to force it to null when unreffing. Maybe if the sink was set externally there is some use case that we should keep it in non-null? * Can't think of any, but I'd like someone to look at this before pushing.
Created attachment 255729 [details] [review] playbin: make sure elements are in null before disposing If a pipeline fails to preroll, it might happen that the sinks are put into READY state from playbin's sink activation, but they are never set to playsink, so they aren't being managed by a GstBin and will keep their READY state until they are unreffed, leading to a warning. Prevent this by always forcing them to NULL when deactivating a group
Comment on attachment 255729 [details] [review] playbin: make sure elements are in null before disposing This will break gapless playback. You must only handle the states of the sinks inside playbin if they're not inside playsink yet.
commit f8d8a56d7bb594d2f7de2d73bb435d19139df2b8 Author: Thiago Santos <ts.santos@partner.samsung.com> Date: Tue Sep 24 16:47:52 2013 -0700 playbin: make sure elements are in null before disposing If a pipeline fails to preroll, it might happen that the sinks are put into READY state from playbin's sink activation, but they are never set to playsink, so they aren't being managed by a GstBin and will keep their READY state until they are unreffed, leading to a warning. Prevent this by always forcing them to NULL when deactivating a group https://bugzilla.gnome.org/show_bug.cgi?id=708789 Just noticed I forgot to fix the commit message when fixed the code, it only forces it to null when not inside playsink.
Might make sense to backport this to 1.2