On Mon Jun 24 09:46:50 2024 +0000, Torge Matthies wrote:
I was just working with the `uridecodebin`-based media source in Proton, not writing a new network media source. Adding concurrency here works around a Gstreamer bug, which essentially requires that all (enabled) streams are constantly drained (or none are) to make forward progress. I am trying to write a minimal reproducer for it. I assumed that having truly asynchronous sample requests would be a desirable thing anyway, but if that is not the case I can leave it out for now.
Given that native file-based media sources are just demuxers I think they don't need concurrency.
The way it is implemented right now, with a decoding pipeline and queues is the cause of the issue, and IMO it should be resolved by making the media source closer to native, like I want to do with !3606.