decodebin3: sending gst_event_new_select_streams() freezes GUI thread under certain conditions

I'll try to describe the conditions of the bug as best I can. I'm using gst-plugins-base 1.16.2 and gstreamer 1.16.2 in a Qt application. My pipeline is based on playbin3. I'm playing a short 3.8 second mp4 video. playbin3 automagically creates a decodebin3 for my video, which contains a GstParseBin with a QTDemux element connected to a GstMultiQueue. Code from QTDemux is being run in a background thread periodically; I assume this is to process and render video frames, or "samples". According to gst debug logs, the mp4 video I'm playing is composed of 1 segment, which is broken into 114 samples. After the 114th sample is processed, the background thread declares that "All streams are EOS" and attempts to "drain" all streams. I don't know what this means.

The first half of this bug requires us to pause the pipeline right after the 114th sample is processed, but before the background thread can see there isn't a 115th sample and begin processing GST_EVENT_EOS. If you pause right at that moment, the background thread will continue working anyway, processing GST_EVENT_EOS, then block for some reason on a line in GstMultiQueue (apparently waiting for the queue to not be full). The background thread seems to be blocked indefinitely until the player returns to the PLAYING state.

The second half this bug is trying to send gst_event_new_select_streams() while the background thread is paused. The background thread, on its way to inspecting the multiqueue, acquires a lock for the decodebin3 bin object. This lock is needed by the GUI thread to send gst_event_new_select_streams() apparently, so the GUI thread blocks too, waiting for the background thread to release the lock. This is the entirety of the bug. I believe GStreamer needs to gracefully handle receiving gst_event_new_select_streams() while the video is paused and in this state. It should not freeze the GUI thread.

Attached is a stack trace with personal comments analyzing the lockup issue. Unfortunately, the window of time in which pausing causes this issue is really narrow so I wasn't able to create a concise working example. I personally use brute force and multiple video player instances (~30) playing short videos on loop being paused all at once to reproduce the issue. gdb.txt