threadshare: panic when dealing with event from non-threadshare element in two successive threadshare ones
gst-launch-1.0 udpsrc port=50000 address=0.0.0.0 ! ts-jitterbuffer latency=80 context="1" context-wait=10 ! ts-proxysink
My actual use case is more complicated and has ts-udpsink instead of ts-proxysink, but that element hasn't been upstreamed yet.
Breakdown of the problem:
- udpsrc pushes stream-start
- jitterbuffer handles the event in its sink_event function, returns a future which runtime/pad.rs handles by calling block_on, as we're not in a context thread
- runtime/pad.rs tries to push the "prelude" for the src pad, aka pad context event
- proxysink handles the event in its sink_event function the same way, returns a future which runtime/pad.rs tries to handle by calling block_on, as we're still not in a context thread
As far as I can tell, the faulty section is most likely in https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/blob/master/gst-plugin-threadshare/src/runtime/pad.rs#L1096-1140: we enter the else part twice in the udpsrc thread, and the comment it contains does not match the actual situation:
// - If there is no PadContext, we don't have any other options. // - If there is a PadContext, it means that we received it from // an upstream element, but there is at least one non-ts element // operating on another thread in between, so we can't take // advantage of the task queue.
Here, we do have a PadContext, and there was no non-threadsharing element between the two threadsharing elements, it is true however that we're still operating on a non-threadsharing thread.
I don't know how to solve this correctly, CC @fengalin :)