While the docs do a very good job of describing how & when most messages are sent and how MFTs are expected to respond, the docs for MFT_MESSAGE_COMMAND_TICK and MFT_MESSAGE_DROP_SAMPLES are noticeably lacking.
Other than saying they require Windows 7 or Windows 8, there aren't many clues.
At a guess, I suspect MFT_MESSAGE_COMMAND_TICK is related to IMFSinkWriter::SendStreamTick. And from the use of 'COMMAND' in the name, I'm guessing this is not just a notification that a tick was generated, but rather a command to produce one. What does the message parameter contain? It can't be the Timestamp since it wouldn't fit.
If I'm right about what this is, I don't know how practical it is to expect all MFTs to support it. ProcessMessage says that if an MFT doesn't support a specific message it should just return S_OK. But since this is what I would expect an MFT to return if it DOES support it, does this seem right? Maybe we are supposed to return S_FALSE if we don't support it?
I'm really stumped by MFT_MESSAGE_DROP_SAMPLES. The name doesn't contain either COMMAND or NOTIFY, so I'm not surewhat it might be trying to tell me. Maybe something to do with MF_QUALITY_DROP_MODE? What is its parameter and what should I do if I get one?
One last point: This page says "Some messages require specific actions from the MFT. These events have "MESSAGE" in the message name." But *ALL* messages have "MESSAGE" in the name. Was this supposed to say "COMMAND"? And while you are fixing that, you should either call them 'messages' or 'events,' not both. Maybe something like "Messages that have "COMMAND" in their name require specific actions from the MFT."
Other than saying they require Windows 7 or Windows 8, there aren't many clues.
At a guess, I suspect MFT_MESSAGE_COMMAND_TICK is related to IMFSinkWriter::SendStreamTick. And from the use of 'COMMAND' in the name, I'm guessing this is not just a notification that a tick was generated, but rather a command to produce one. What does the message parameter contain? It can't be the Timestamp since it wouldn't fit.
If I'm right about what this is, I don't know how practical it is to expect all MFTs to support it. ProcessMessage says that if an MFT doesn't support a specific message it should just return S_OK. But since this is what I would expect an MFT to return if it DOES support it, does this seem right? Maybe we are supposed to return S_FALSE if we don't support it?
I'm really stumped by MFT_MESSAGE_DROP_SAMPLES. The name doesn't contain either COMMAND or NOTIFY, so I'm not surewhat it might be trying to tell me. Maybe something to do with MF_QUALITY_DROP_MODE? What is its parameter and what should I do if I get one?
One last point: This page says "Some messages require specific actions from the MFT. These events have "MESSAGE" in the message name." But *ALL* messages have "MESSAGE" in the name. Was this supposed to say "COMMAND"? And while you are fixing that, you should either call them 'messages' or 'events,' not both. Maybe something like "Messages that have "COMMAND" in their name require specific actions from the MFT."