However, I suspect that no application has ever used SetReadStreamSamples() in this way
[I am inclined to agree.](https://gitlab.winehq.org/wine/wine/-/blob/28fe6207e909178c588f111645157c88a...)
Also, the slow part of initialization does seem to mostly be autoplugging
If you mean the typefind element is slow, it can be removed by setting sink-caps on the decodebin to video/x-ms-asf; it's not like a WMSyncReader should get any other input. And if it does, erroring out is the correct behavior, which it will if given those caps.
If you mean it's slow to map caps (video/x-ms-asf) to decoders/demuxers (asfdemux), yeah, can't solve that one. But I doubt it is, GLib has plenty of hashmaps and stuff and the GStreamer devs know how to use them.
If you mean it's slow to check which GStreamer plugins exist, yeah, can't solve that one either, but at least it's once per process, at most.
we need a way to identify which compressed format corresponds to which stream
Good point, can't do that with just gst_bin_iterate_elements.
But there's plenty of other introspection functions available. For this task, I'd take the stream's pad, find the avdec_wmv3 (or whatever) element inside the decodebin (gst_ghost_pad_get_target + gst_pad_get_peer + gst_pad_get_parent_element), then check that element's sink pad's caps (gst_element_iterate_sink_pads or gst_element_foreach_sink_pad, then gst_pad_get_current_caps).
Sure, the memory management could be a little fiddly (especially around GstIterator), but I'm not seeing anything difficult or really ugly.
I'm tempted to implement exactly that, just to prove which of us is wrong. But let's get this one or !3970 in place first, I don't want to have too much in flight at once.