If you just want to know the format, I'd let decodebin finish construction, then check what's inside. A decodebin is a GstBin, you can just call gst_bin_iterate_elements or something on it.
Sure, but that gets ugly. We'd have to find the demuxer, which is not always trivial.
If you want to be able to switch, like wmvcore!WMCreateSyncReader, I think the best solution would be creating a new decodebin with different target caps.
Yes, I'm kind of inclined to agree with this actually. The current design was meant to account for the fact that IWMSyncReader::SetReadStreamSamples() is supposed to be able to toggle while "streaming", and the way we currently implement that actually... kind of works. However, I suspect that no application has ever used SetReadStreamSamples() in this way, and the code is kind of uglier than it needs to be.
The main reason that I think we probably still want two decodebins is:
* in order to implement IWMMediaProps::GetMediaType(), we either need to retrieve the compressed format from the "uncompressed" parser, or we need to create two wg_parser objects. I worry about the latter being slow. [There may be other ways around this, though. Also, the slow part of initialization does seem to mostly be autoplugging, so maybe that's not a concern.]
* in order to retrieve the compressed format, we either need to introspect the pipeline, which I think is difficult and really ugly from an API perspective, or we use callbacks like autoplug-continue to be notified of it.
* if we use autoplug-continue, we need a way to identify which compressed format corresponds to which stream. By just plugging another decodebin we can get that inherently.