The winegstreamer API seems fine, but I don't think that approach of retrieving the stream format is quite what we want. I believe the right approach to actually outputting uncompressed data is to use autoplug-continue, so we should use the same signal to find out what the uncompressed format is; that way we know the logic matches. By contrast, this patch could retrieve a compressed format that isn't the "initial" compressed format, or (theoretically?) fail to retrieve a compressed format altogether.
The trick there is matching the pad from autoplug-continue with the pad from pad-added. I've given this some thought and I have two potential ideas here:
(1a) Keep track of pads returned from autoplug-continue in a list, adding a reference to each one. When we get pad-added, walk the list of pads upwards until we find a pad in the autoplug list.
(1b) Keep track of pads returned from autoplug-continue in a list, adding a reference to each one. Install a pad probe on each one as well. When we get pad-added, send a custom query to the downstream pad, and catch it with the pad probe.
(2) Always return FALSE from autoplug-continue for recognized compressed formats. If the format is compressed and we are configured to return uncompressed data, append a second decodebin. Unsurprisingly, GStreamer is designed so that this is actually a pretty reasonable thing to do. There's a (negligible) bit of overhead from the extra bin, but the configuration of elements shouldn't actually change at all. Worth noting is that decodebin will *not* add a multiThat aside, a few extra comments on this queue if there's no parser and use-buffering isn't configured to TRUE; both of these will be the case here and that's what we want (we already have the multiqueue earlier). This also might allow us to toggle compression without recreating the entire wg_parser (by detaching the stream's decodebin), though I haven't fully thought this through and it's not like it matters that much anyway.
The more I think about it, the more I like (2). (1a) seems conceptually ugly and is probably a pain to implement; (1b) is less bad but honestly (2) just seems simpler, both practically and architecturally.