On Wed Apr 3 01:38:19 2024 +0000, Brendan McGrath wrote:
it should be as light as it is on Windows and not decode samples
Is this in reference to an ongoing design discussion? If so, I'm not sure what the path forward is for this issue/MR?
Yes, this is a big difference in the way the media source is implemented, and it causes all sorts of issues in other places. I've been slowly working toward changing it but it requires a lot of changes in the MF pipeline to support it.
Many applications implicitly or explicitly depend on MF pipelines exposing similar components as on Windows (source -> decoder -> converter -> sink), and we should implement the same kind of thing for compatibility. If the decoders are taking a long time to decode and stall each-other, it should be solved by making them as concurrent as they are on Windows.
There's also some diverging opinions on how the media source itself should be implemented, where I would like to use a separate unix interface to make it simpler and synchronous, while @zfigura doesn't want that.