GNOME Bugzilla – Bug 574163
Fix gst_pad_activate_pull deactivation with unlinked element
Last modified: 2009-03-05 10:37:24 UTC
When de/activating a pad in pull mode the pad needs to de/activate the peer pad it is connected to, failure to be able to do this in activation mode is an error. However failure to do it in deactivation mode is not an error imho as long as something else deactivates that pad which is very likely, and even if nothing does I'm don't think it's worth making the deactivation of the pull element fail. In my situation as I unlinked an element in the PAUSED state (without any dataflow), before setting it's state to NULL, the pad thread leaked since it could not deactivate it's pad as it was unlinked. ( I know that's not the best senario but it shouldn't cause a leak...) Fixed code to make only the activation case an error. please review /comment...,
Created attachment 130060 [details] [review] Fix pull mode pad deactivation
commit fe2f12b162d66d089af8610444d9f8b28bde0cf7 Author: Antoine Tremblay <hexa00@gmail.com> Date: Thu Mar 5 11:29:48 2009 +0100 GstPad: relax failure to deactivate unlinked pads When de/activating a pad in pull mode the pad needs to de/activate the peer pad it is connected to, failure to be able to do this in activation mode is an error. However if there is no peerpad, we can still deactivate the pad correctly and assume the application will deactivate the unlinked peer pad eventually. Fixes #574163.