This bothers me, actually, because in theory gstreamer's multiqueue should prevent this. It's designed to try to buffer streams evenly, but if one stream is getting starved it *should* allow to increase the buffering limits on the others to prevent a deadlock. I think we should investigate why this isn't working correctly.
Maybe the answer is trivial: soon after `Shutdown()` is called, `gst_element_set_state(GST_STATE_NULL)` is called, and I guess it's totally reasonable that after that GStreamer stops sending samples. So either we go with solution 1 or we have to rearchitecture the shutdown logic so that when `Shutdown()` is called the WG parser first checks that at least one sample is available for each enabled stream and then stops GStreamer. And right now I fails to see which advantages that would bring (until we have a proof that native does solution 2 or 3).