GNOME Bugzilla – Bug 164168
circular pipeline fails to negotiate
Last modified: 2005-11-14 10:49:48 UTC
Please describe the problem: I'm not sure if opt should handle this more gracefully, so I'm filing it for discussion. gst-launch identity name=i ! i. ** ERROR **: file gstoptimalscheduler.c: line 879 (add_to_group): assertion failed: (GST_ELEMENT_SCHED_GROUP (element) == NULL) Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
In 0.9, this deadlocks when linking. gst_pad_link_prepare will grab the object lock of both pads in a link, and then sequentially call get_caps_unlocked on both of them. get_caps_unlocked will release the object lock, call the pad's getcaps function, then reacquire the lock. However while e.g. the lock is released on the src pad, the sink pad's lock is still held. So if one pad, during the course of its getcaps, ends up coming back to getting its peer's caps, negotiation will lock up. Of course there is the IN_GETCAPS flag that's designed to prevent this from happening, but you can't read it if the object's lock is taken, which in this case it is, from pad_link_prepare. Besides that, there's the question of what this pipeline should do. Because neither pad will start a task, this should go to PLAYING but not do anything. Dude, where's my dataflow? Copying wim for comment, renaming, severity normal, retargeting to 0.9.x (the link_prepare having locks *is* a bug).
1) linking pads should have the same grandparents, this would make this link fail. 2) other loops in the pipeline can be detected while doing the state change 1) is fixed in HEAD CVS, the pad link simply fails with a WRONG_HIERARCHY error code.
AFAIK 2) is fixed with the new bin state change algorithm. Closing, foolios.