How to cope with Microsoft's design flaw of the MFT_MESSAGE_NOTIFY_END_OF_STREAM message, when using the standard media session pipeline with multiple input MFTs ?

Question

Hello!

I dont know if this is the right place to ask the following question. But since the MSDN was shutdown by MIcrosoft a few years ago this seems to be the only place.

And i will not ask it on Stackoverflow, as i would propably be the best candidate to answer all the questions over there for most people. I propbaly know Microsoft's OS better than themself, as i am a reverse engineer guy and a master of over 20 Low-Level APIs in Windows, and know a lot of backdoors aswell. Dont worry, i am white hat, and i am on your side.

I am asking the following question only because Microsoft messed up the design of their aggregate source and standard media session (IMFMediaSession) implementation.

I am about to release some of the most cleanest written and optimized multiple input MFTs worldwide. And my MFTs would work seamlessly with all of Microsoft's standard media pipelines. But one event that was not patched through correctly by MIcrosoft literally put 7 years of effort to a hold.

The problem is that Microsoft's pipeline does not pass the MFT_MESSAGE_NOTIFY_END_OF_STREAM message downstream, and thus an MFT cannot know when some streams end earlier than the others. With only live sources hooked to the MFT it is no issue, as there is no end of stream. However, when you have only file sources, or live sources with file sources mixed, then an MFT cannot process further when one stream ended. Simply because there is no information about it.

See, ... MIcrosoft even states that "The client is not required to send this message". And the Media Foundation developers at MIcrosoft took that literally among each other and developed the standard media session created by MFCreateMediaSession exactly that way. And so the MFT_MESSAGE_NOTIFY_END_OF_STREAM is never send downstream to MFTs. That prohibits writting multiple input MFTs where some streams can end earlier than the others. It is a major design flaw.

The problem:

When you have file sources hooked to the MFT, no matter if in combination with live sources or not, then some streams can end earlier than the others. The MFT does not know about it because the message was not patched through/downstream, and thus the MFT cannot process further the remaining streams. It is a major design flaw and has to be fixed asap.

I mean i can write my own custom aggregate source, and patch the message through, but that would not only take a few month more in work, but also renders Microsoft's own aggregate source created by MFCreateAggregateSource useless.

How to cope now ? I am only a few weeks away from the release of some of my MFTs.