GNOME Bugzilla – Bug 740694
decodebin: Take STREAM_LOCK before sending sticky events.
Last modified: 2014-11-26 18:44:33 UTC
There was a race where: 1) we would put the element to PAUSED 2) It would get data sent to it from upstream 3) It would thus send caps 3) caps_notify_cb would continue autoplugging 4) caps would flow downstream, the last pad would get exposed 5) we were still not done sending the sticky events Taking the stream lock on the new element's sinkpad and only releasing it when sticky events have all been sent prevents the caps from reaching the source pad of the element before we're all set.
Created attachment 291473 [details] [review] decodebin2: Take STREAM_LOCK before sending sticky events.
Review of attachment 291473 [details] [review]: Looks good except for a typo ::: gst/playback/gstdecodebin2.c @@ +2371,3 @@ + /* First lock element's sinkpad stream lock so no data reaches + * the possible new element added when caps are sent by element + * while we're still sending stickies */ sticky events you mean, not stickies ;)
Created attachment 291474 [details] [review] decodebin2: Take STREAM_LOCK before sending sticky events. There was a race where: 1) we would put the element to PAUSED 2) It would get data sent to it from upstream 3) It would thus send caps 3) caps_notify_cb would continue autoplugging 4) caps would flow downstream, the last pad would get exposed 5) we were still not done sending the sticky events Taking the stream lock on the new element's sinkpad and only releasing it when sticky events have all been sent prevents the caps from reaching the source pad of the element before we're all set.
Created attachment 291480 [details] [review] decodebin2: Take STREAM_LOCK before sending sticky events. There was a race where: 1) we would put the element to PAUSED 2) It would get data sent to it from upstream 3) It would thus send caps 3) caps_notify_cb would continue autoplugging 4) caps would flow downstream, the last pad would get exposed 5) we were still not done sending the sticky events Taking the stream lock on the new element's sinkpad and only releasing it when sticky events have all been sent prevents the caps from reaching the source pad of the element before we're all set.
Author: Mathieu Duponchelle <mathieu.duponchelle@opencreed.com> Date: Tue Nov 25 16:46:50 2014 +0100 decodebin2: Take STREAM_LOCK before sending sticky events. There was a race where: 1) we would put the element to PAUSED 2) It would get data sent to it from upstream 3) It would thus send caps 3) caps_notify_cb would continue autoplugging 4) caps would flow downstream, the last pad would get exposed 5) we were still not done sending the sticky events Taking the stream lock on the new element's sinkpad and only releasing it when sticky events have all been sent prevents the caps from reaching the source pad of the element before we're all set. https://bugzilla.gnome.org/show_bug.cgi?id=740694
Review of attachment 291480 [details] [review]: commited