Questions regarding MFT implementation
Hi,
I have some questions regarding MFT:
1) How to get topology loader enum my MFT? I register my MFT in MFT decoder category, but it's not enum'ed when I set a partial topology to media session.
2) I try to get D3D manager as mentioned in previous threads, but I found IMFTransform::GetAttributes is never called.
3) When output format changes, I set pOutputSamples[0].dwStatus = MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE and return MF_E_TRANSFORM_STREAM_CHANGE in IMFTransform::ProcessOutput. But no one try to get my new preferred output type. Is there anything I need to take care?
Thanks in advance.
Patrick
[652 byte] By [
Patrick0] at [2007-12-22]
Hi Patrick,
1) So it sounds like you did call MFTRegister() to register your MFT in the appropriate decoder category and with the appropriate input and output types. So it should be getting enumerated. To narrow down the problem, I might recommend just making a call to MFTEnum in your test code and seeing if your MFT appears in the enumeration.
2) I think this has something to do with #1. The MF topology loader sets up the D3D stuff only if it has inserted your MFT as a decoder, which, from #1, it sounds like it hasn't. I'll bet this problem will go away when you fix #1.
3) The MF_E_TRANFORM_STREAM_CHANGE error code together with the MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE status should trigger some media type negotiation activity at your MFT. To help narrow down this problem -- do you subsequently see any more activity at your MFT (like any more ProcessInput/ProcessOutput), or does the entire pipeline appear to have stopped moving at this point? That might help us figure out where this is coming from.
Becky
Becky,
Thanks for your help. I'll check the MFTEnum function.
For (3), yes I see subsequent ProcessInput/ProcessOutput calls. If I clear the output type and return MF_E_TRANSFORM_TYPE_NOT_SET, the pipeline will stop and return error.
Patrick
Useful info... Thanks for reporting.
All right, I think we need to do some work here to reproduce this problem internally. I'll follow up on this thread if I need any more info from you while we do this.
Becky
Hi,
Actually, I also encountered the same issue as Patrick.
No matter I set pOutputSamples[0].dwStatus = MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE and return MF_E_TRANSFORM_STREAM_CHANGE in IMFTransform::ProcessOutput(), or return MF_E_TRANSFORM_TYPE_NOT_SET in IMFTransform::ProcessInput(), it both make the pipeline stop and return error.
If the current mechanism of Dynamic Format Change does not take effect, could you give us some advices that how we can implement this operation right now?
Thanks.
Charles
All right, we've done a bit of work to try to figure out what both of you might be hitting (thanks for your patience).
So after you signal the output type change (i.e. MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE + MF_E_TRANSFORM_STREAM_CHANGE), this does prompt the MF pipeline to try to figure out the best media type to try to continue with.
Here's how this looks from your MFT's perspective:
1) The MF pipeline makes a call to pYourMFT->GetOutputCurrentType(). We know of a bug where -- if you have removed your "current output type" at this point, the pipeline will hit an error and stop, like Patrick says. This will be fixed before we ship, but for right now, you can work around it by just keeping your old output type around. I'm going to guess this may be your issue as well, Charles.
2) Right after that, you should see one or more calls to pYourMFT->GetOutputAvailableType, from which you should return your new set of possible output types. The MF pipeline will try to figure out what the right one should be, and calls pYourMFT->SetOutputType with it. Then it propagates this format change downstream through the rest of that branch of the topology.
So try looking for these calls, and let me know if you're seeing something different. (If so, a detailed list of exactly what calls your MFT receives and in which order will probably be useful to us.)
Becky
P.S... We know of a couple of other bugs around this feature (MFT-initiated dynamic format change) that might cause processing to stop with no errors reported, after all of the steps I outlined above happen. These will be fixed before we ship... But be forewarned that you might hit them now.
Thanks again for reporting what you saw... As you can tell, this feedback is very helpful to us!
Hi Becky,
Thanks for your response.
I've done the following operations in my MFT implementation.
a) When output format is going to be changed, ProcessOutput() return MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE + MF_E_TRANSFORM_STREAM_CHANGE.
b) If the output format change operation is not completed, ProcessInput() return MF_E_TRANSFORM_TYPE_NOT_SET.
And here is my test result.
1) I have not removed my "current output type". However, after ProcessInput() returns MF_E_TRANSFORM_TYPE_NOT_SET, the playback stops immediately. And GetOutputCurrentType() has never been called.
2) If ProcessInput() continues returning S_OK instead of MF_E_TRANSFORM_TYPE_NOT_SET, the following functions will be called:
(a) GetOutputStreamInfo(), return S_OK.
(b) ProcessOutput(), return MF_E_TRANSFORM_STREAM_CHANGE.
(c) Repeat GetOutputStreamInfo() and ProcessOutput() several times then the playback stops.
The GetOutputCurrentType() is still never called.
By the way, I am using beta 2 SDK for my implementation, and my OS version is Vista Beta 2, Build 5384.
Charles
Hi Becky,
I've upgraded my OS and SDK to 5600 version and tried the operations again, and it works. Thanks!
The calling sequence during the type change in my observation is as follows:
1. pMyMFT->ProcessOutput() return MF_E_TRANSFORM_STREAM_CHANGE with MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE in pOutputSample[0].dwSatus.
2. pMyMFT->GetOutputAvailableType() is called.
3. pMyMFT->SetOutputType() is called.
4. Type Changed successfully in MyMFT.
Could you confirm the above calling squence is correct since there is slightly differece from your early mention that GetOutputCurrentType() is not called during the operations?
Anyway, 5600 has fixed many issues and is more reliable. Thanks for your great help! 
Charles
