GNOME Bugzilla – Bug 676003
fails to pull in push mode due to check for already activated pad removed
Last modified: 2012-05-14 10:56:58 UTC
Created attachment 213976 [details] [review] do not change mode if pad is activated even if caps are forced In commit bf0964b6 a check for pad is activated was not carried. This leads to attempt to pull while in push mode when force_caps is set. In this case without the attached check even when activated in pull mode we activate back to push mode. This is from comment in previous code , case number eight: 8. if the sink pad is activated, we are in pull mode. succeed. - otherwise activate both pads in push mode and succeed. Putting it back fixes playback of webm in webkit+gstreamer 1.0 .
I don't understand.. The activate function is called when the pad is not active so gst_pad_is_active() would always return FALSE and your code simply does nothing. Can you attach a compressed GST_DEBUG=*:9 log or maybe a way to recreate the problem with playbin?
Ah, I just saw it, it's the signal that can make the pad activate in a different mode..
your patch does not release the object lock.
argh, ignore me..
commit 10396f12d43ed7d7b10aae556ba1b2a2ec4e6cba Author: Alban Browaeys <prahal@yahoo.com> Date: Mon May 14 03:57:50 2012 +0200 typefindelement: if sink pad is activated do not change mode In commit bf0964b6 a check for pad is activated was not carried. This leads to attempt to pull while in push mode when force_caps is set. In this case without the attached check even when activated in pull mode we activate back to push mode. This is from comment in previous code , case number eight: 8. if the sink pad is activated, we are in pull mode. succeed. - otherwise activate both pads in push mode and succeed. Putting it back fixes playback of webm in webkit+gstreamer 1.0 . Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676003