GNOME Bugzilla – Bug 746442
rtprtxsend: Maybe broken stream lock handling
Last modified: 2015-03-19 11:41:42 UTC
Currently rtprtxsend is sending data and events from the sinkpad streaming thread, and from its own srcpad task. The srcpad task holds the stream lock of the srcpad all the time, and pushing data/events will take the stream lock of the peer pad. I'm not sure if the attached patch is really necessary, maybe by taking the peer pad stream lock everything is good already... but maybe not. Maybe what can happen is that we store serialized events out of order on the srcpad itself or something.
Created attachment 299799 [details] [review] rtprtxsend: Take the stream lock before doing anything with the srcpad
I don't think this is needed. The srcpad has it's own lock and pushes independently from the other threads, there is no need to serialize things beyond that, AFAICS.
But the srcpad stream lock will only be taken by the task, not by gst_pad_push/gst_pad_push_event. So only the task will ever take that, while the chain/event function will just push things without. However gst_pad_push/push_event will take the stream lock of the peer, so maybe it's all good.
(In reply to Sebastian Dröge (slomo) from comment #3) > However gst_pad_push/push_event will take the stream lock of the peer, so > maybe it's all good. Yes, we serialize buffers and events on the sinkpads of elements.
So probably no problem here then.