locked
Decoding using H.264 Video Decoder RRS feed

  • Question

  • Hello,

    I am trying to decode h.264 frames in my application using the Microsoft H.264 Video Decoder on Win7 by providing it input from a file containing the encoded H.264 bitstream. I created this input file by running the x264 encoder on a sample .yuv file to generate a .264 file.

    The decoder provides the output media types IYUV, NV12, YUY2, YV12 after I set the input media type to MFMediaType_Video & MFVideoFormat_H264. I set YV12 as the output type. After this I started providing it chunks of data using ProcessInput. However even after feeding it the entire file (> 250 frames), GetInputStatus still returns MFT_INPUT_STATUS_ACCEPT_DATA, and ProcessOutput too indicates that the decoder needs more input.

    Any ideas on what might be going wrong? I have tried setting more attributes of the input media type, like frame rate, resolution, interlace mode etc. as suggested here: - http://msdn.microsoft.com/en-us/library/windows/desktop/dd797815(v=vs.85).aspx 

    To rule out problems with the input, I encoded the same source .yuv file into .mp4 format using x264 encoder, and when I tried to play that using graphedit, I saw it was accepted by the Microsoft decoder and was played properly. 

    I also tried using the decoder with one of the h264 files from here:- ftp://ftp.ldv.ei.tum.de/videolab/public/TUM_1080p25_Data_Set/LC/ but I got the same behaviour as before.

    Please let me know if you had suggestions...   

    Thanks

    Thursday, February 9, 2012 6:34 AM

Answers

  • I was able to get some output finally from ProcessOutput, although I need to render it to see if it is alright. The issue was resolved when I added the call '

    SetCurrentLength' for the buffers being sent to the input, to correctly set the size of the buffers.

    Its not clear why GetOutputStatus does not ever return MFT_OUTPUT_STATUS_SAMPLE_READY, even when ProcessOutput returns an output?

    Wednesday, February 15, 2012 12:20 PM

All replies

  • I was able to get some output finally from ProcessOutput, although I need to render it to see if it is alright. The issue was resolved when I added the call '

    SetCurrentLength' for the buffers being sent to the input, to correctly set the size of the buffers.

    Its not clear why GetOutputStatus does not ever return MFT_OUTPUT_STATUS_SAMPLE_READY, even when ProcessOutput returns an output?

    Wednesday, February 15, 2012 12:20 PM
  • The H264 decoder in Win7 had a bug where it never set the MFT_OUTPUT_STATUS_SAMPLE_READY flag.  The way the MF platform uses MFTs, it never checks this flag but just checks if ProcessOutput returns an error.
    Tuesday, March 20, 2012 12:45 AM
  • Thanks for clarifying this.

    I am using the decoder to decode a stream from a Logitech C920 webcam that provides H.264 encoding in the hardware. I notice a huge delay between the first processinput, and the first succesful return from processoutput. The decoder returns 'MF_E_TRANSFORM_NEED_MORE_INPUT' for nearly one second before it starts producing the output samples. This causes a noticeable lag in the video. I have been unable to compare the behaviour in topoedit, where the graph refuses to play saying 'incompatible media type'. I have also tried comparing using graphedit by connecting the 'Microsoft DTV-DVD Video Decoder' to the appropriate pin of the webcam and saw the delay is much less (around 200-300ms)

    Is there any sample code that I could use to compare this behaviour of the MFT decoder and figure out if this is expected behaviour? I have used the CoreAVC decoder to decode the same stream and the delay there too was very low (around 200ms).

    Thanks

    Friday, March 30, 2012 10:54 AM
  • hi,

    the delay you encounter is also mentioned here and here. i guess this is due to internal buffering (maybe it has to buffer a whole GOP). The only alternatives i can suggest is using a different h264 decoder MFT . using another mft (custom one) i was able minimize the delay for live h264 sources to far below 100msec

    Friday, March 30, 2012 11:36 AM
  • Hi,

    Thanks for this extra information. Looks like this inherent delay is an officially acknowledged limitation (I wish this was mentioned in the main documentation itself :) ). I wonder how much the 'MF_LOW_LATENCY' flag improves things on Win8.

    Did you get much better results by wrapping ffmpeg's decoder in an MFT, or did you have to write your own?

    Thanks

    Monday, April 2, 2012 6:18 AM
  • I was just about to post a question about this. I wasted too many hours trying to get a simple decoder to work - I was sure I had everything implemented according to the documentation, but frames never came out. I was of course following the Basic MFT processing model documentation, and was checking for the MFT_OUTPUT_STATUS_SAMPLE_READY flag.

    Thanks for clarifying - if only Microsoft saw it fit to document such glaring bugs in the MSDN documentation and not via volunteers and moderators in dev forums!

    Thursday, April 11, 2013 3:02 AM
  • I have a follow-up question. Might as well ask here since I may be running into another undocumented bug.

    After some 20 odd frames have been passed into the decoder, ProcessOutput returns MF_E_TRANSFORM_STREAM_CHANGE. There is no frame output. The very next time I call ProcessInput it fails with MF_E_NOTACCEPTING, and the decoding gets corrupted. 

    Am I supposed to call ProcessOutput again after MF_E_TRANSFORM_STREAM_CHANGE before calling ProcessInput again? I tried this, and got the first frame out. Still, the next time ProcessInput is called, it fails again with MF_E_NOTACCEPTING.

    What does the MFT H.264 decoder expect us to do when it's not accepting input in a synchronous decoding model? I am sitting on an input buffer I cannot discard without causing output corruption, and since it's expected to behave synchronously with one thread (in my app), I have no easy way of outputting another frame at this point. Do I have to keep pulling frames out of the decoder until it returns MF_E_TRANSFORM_NEED_MORE_INPUT before it will start accepting frames on its input again?

    Thanks!

    Thursday, April 11, 2013 5:36 PM
  • To answer my own question. Yes, one has to pull all available frames out of the decoder before it will start accepting input again. It seems I have to re-write my application around this behavior.

    Thursday, April 11, 2013 6:30 PM
  • where  to setcurrentlength? 

    instance of which interface in media foundation?

    Monday, July 21, 2014 8:35 AM