locked
The Microsft H.264 decoder MFT ProcessInput() failed even though GetInputStauts() reports MFT_INPUT_STATUS_ACCEPT_DATA RRS feed

  • Question

  • The original post is "Microsoft H.264 decoder MFT sometimes outputs corrupted frames under Windows 8": My program works fine in Win7, but sometimes outputs corrupted frames in Win8. -- Sorry about that, the root cause is that my program doesn't expect the failure of MFT ProcessInput() (returns MF_E_NOTACCEPTING). The decoder itself has no problem. But I still have some questions:

    1. Why the ProcessInput() failed even though GetInputStauts() reports MFT_INPUT_STATUS_ACCEPT_DATA? Does it mean that GetInputStauts() is unreliable?
    2. Does the Microsoft H.264 decoder MFT in Win8 have lower response speed than in Win7? In Win7, my program never encountered failure of ProcessInput().
    3. Should the data input to the MFT be aligned to NALUs or frames [1]? By input unaligned data, my program still works fine under Win7.
    4. Should we use the new media subtype "MFVideoFormat_H264_ES" introduced in Windows 8 SDK?

    [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa370819(v=vs.85).aspx


    • Edited by tcplus Friday, October 5, 2012 6:38 AM
    Friday, September 28, 2012 8:45 AM

All replies

  • (1) This is a bug in the H264 decoder MFT.  GetInputStatus is not normally called by the MF pipeline so this was not noticed in previous testing.  The way it works now, it will always return MFT_INPUT_STATUS_ACCEPT_DATA, regardless of whether or not the MFT can accept samples.

    (2) Changes were made in Windows 8 to lower the latency of the H264 encoder.  This resulted in it requiring fewer samples on the input before it generates an output sample.

    (3) Input samples should be Annex B with start codes.  That said, the decoder is fault tolerant and may handle other data formats if it can find the frames in them.

    (4) MFVideoFormat_H264_ES is for elementary streams where there is not a 1:1 correspondence between samples and frames.  For example, this would be the case for an H264 stream stored in an MPEG2 file.  If your code is already working with MFVideoFormat_H264 and you are able to generate samples with individual frames, you should not use the new media type.

    Thursday, October 25, 2012 10:09 PM