GNOME Bugzilla – Bug 787323
ghostpad : Issue in setting pad mode for a bin created dynamically(when pipeline is running)
Last modified: 2018-11-03 12:42:30 UTC
Created attachment 359221 [details] Sample application to reproduce the issue(based on test-segment-seek) I have had this issue in my application which I'm able to reproduce in a small testbench I have a pipeline gst-launch-1.0 playbin uri=xxx.mp4. When this file xxx.mp4 play is done, 1. I create another srcBin ! typefind ! sink branch and add to the pipeline(and link). SrcBin is a bin encapsulating filesrc 2. Call gst_bin_sync_children_states() I see that the filesrc's pad activation function called 3 times, pull-pull-push mode. However, typefind thinks the pad in PULL mode. And this gives error *pull range on pad bin_src_pad:proxypad16 but it wasnot activated in pull mode* No such issue is seen is srcBin is replaced with filesrc(make #if 0 in line 156) It seems like some bug in ghostpad's pad activation when done when pipeline is running
Created attachment 359223 [details] Testbench with more comments and removed unnecessary code
This is not a clear cut example that it's proxypad's fault. The aforementioned example is the only time I can reproduce this. - Adding the new elements to a new pipeline does not exhibit the problem. - Replacing typefind with identity does not exhibit the problem. - Starting the two branches together (i.e. don't finish playing the file in playbin and then add elements) does not exhibit the problem.
This happens with only those elements who work in pull mode(typefind). Hence we dont see the issue with the typefind It is a right observation that starting both the branches together do not cause any issue. Some undesired things happen when we call gst_bin_sync_children_states(). Filesrc decides to work in pull mode initially upon which typefind calls for get_range. But in-between that, filesrc decided it will work in PUSH, which causes this assertion
*Hence we dont see the issue with the identity
-- 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/gstreamer/issues/249.