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.
Why does quartz deadlock? Read requests shouldn't block, and while sample requests can block they should be resolved by earlier samples getting delivered, which shouldn't deadlock.
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.
Sure, but there's also no known application that depends on that detail. I don't like the idea of making the parser interface that much more complicated if it's not necessary.