Rémi, I see you've effectively NAK'd this patch. I don't know if that's intentional.
If it is, I will point out a few things:
* How many formats the media source outputs is orthogonal to whether it outputs any at all. Even if the arguments against ever outputting decompressed video held weight—which I believe they do not—none of them are arguments against adding additional formats, as patch 5/5.
* Any application that wants a specific format (in this case, BGRx) is pretty much by definition autoplugging to that format. While applications *can* access the underlying media source from the source reader, it is vanishingly unlikely that they will depend on its output format. The *only* attested or sensible way for applications to depend on receiving uncompressed video is that they try to manually plug graphs.
* At least some native decoders do not output RGB formats anyway, meaning that the only way to get RGB out of a source reader is the way it's done in 81b09cdee, with MF_SOURCE_READER_ENABLE_VIDEO_PROCESSING. This means that in order to implement this in a way closer to native, it would not be sufficient to separate the demuxer and decoder; rather we would need to manually decode YUV to RGB in the media source. Besides adding more overhead to the pipeline, as well as more complexity should it need to be debugged, this will require much more work to implement (and for only particularly unlikely theoretical benefit).