With the exception of the read thread, yes. But the read thread is conceptually just a hack that exists because we can't just do callbacks. The point I was trying to make is that wg_parser is synchronous (like the wmvcore sync reader, or mfplat) and not asynchronous (like the wmvcore async reader, or quartz).
That said, I see what you mean by synchronous vs asynchronous, and the issue you're getting at, so thanks for bearing with me.
However, I don't like exposing that asynchronicity to the PE side if we can avoid it, or having a different API between parsers and transforms when we don't need to. That could mean waiting in parser_request_sample () until we get wg_parser_stream_get_sample().
The disadvantage there is that we don't get any buffering on the GStreamer side, though. Maybe that's not a problem, but it's not great to get rid of either.
I still don't like the generalized "request" mechanism; I still maintain it's a lot more complicated than it seems to you. I think my preferred approach, assuming I'm considering everything, is that we'd just introduce an allocation callback which is handled like read callbacks. (Possibly it could use the same thread, and hence also turn read requests back into the gst_cbs infrastructure...)
Like I said above, having allocations done in the reading thread context (as opposed to the output threads context) isn't working for several use cases: it works and is somehow required for mf, but quartz and wmvcore aren't supposed to do that. Quartz in particular quickly ends up with deadlocks because its allocators callbacks are blocking the read thread.
Like I also pointed out, there's several scenarios that simply cannot be solved with the current design, and that can only be solved with either syscall callbacks, which we don't want, or a design similar to the one I've described above.
For instance and as you said, the wmvcore read thread is a hack. I can write a wmvcore test showing that the reading thread isn't supposed to be, and that stream seek / reads calls are supposed to come from the same thread as the caller in the sync reader, as allocs callbacks, and as outputs callbacks in the case of the async reader without dedicated delivery threads.
That alone seems to me enough proof that the design is sane, and more flexible.