I don't think this can work. To the contrary to the wg_transform, which pretty much works in a serialized way, because we buffer the input samples and only provide them to GStreamer when we're ready to receive at least one output, the wg_parser is asynchronous in nature. Input buffers are provided on GStreamer requests, and we should do the same for buffer allocations
Input buffers are different, yes, but I don't understand why output buffers need to be different?
wg_parser isn't really asynchronous in nature, at least not the way I designed it, and I don't think it makes sense for it to be asynchronous. The goal was to make a synchronous API that hides the asynchronous parts of GStreamer. The synchronous API was motivated by the fact that both mfplat and wmvcore have synchronous APIs, the need to control threads with the PE/Unix split, and the fact that I think synchronous APIs are just generally easier to reason with.
I don't think we can reliably assume that buffer allocations are quickly followed by buffer output and that it's safe to wait for the output when we allocated a buffer.
I don't understand these statements either. Why do we care that buffer allocations are quickly followed by buffer output, and why would that assumption be different for transforms vs parsers? What do you mean by "wait for the output when we allocated a buffer"?