Input buffers are different, yes, but I don't understand why output buffers need to be different?
Because GStreamer may want to allocate buffers at times where the only active thread is the reading thread for instance. This is the case with the media source, and allocating buffers from the MF sample request callbacks doesn't work.
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 see how it can **not** be asynchronous when it needs at least two threads, one reading thread that pushes data and at least another one that asynchronously waits and receives the output buffers.
I don't know if mfplat is really supposed to be synchronous and without a reading thread, but I'm pretty sure wmvcore sync reader isn't, and with the current API it's simply not possible to do it (remove the reading thread and use only one thread). With the input / allocation / output requests, it would be.
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"?
Because wg_transform pushes input buffers after we've allocated and prepared an output buffer, and because it all happens synchronously: we never provide input concurrently and if the GStreamer pipeline is synchronous we can be sure that no allocation will be requested before or after the wg_transform_read_data call. If the GStreamer pipeline is asynchronous, any allocation that happens after or before that moment can be denied, though we'd like to avoid this case from the zero-copy perspective.
For the wg_parser, the GStreamer pipeline is always asynchronous, and we always provide input concurrently. Allocations are then unpredictable and, as I described above sometimes required before the PE side is ready to handle them.