H.264 decoder. Header with non key frame

[Alex_S_16]

Have a good time! I have an abnormal situation - some cameras generates the non key frame, but sometimes this camera adds the "extra data" (i.e. header) at the begin of non key frame. The "scenario" is - one frame in given buffer. The MFXVideoDECODE_DecodeHeader() in this case (as in case of I-frame) returns MFX_ERR_NONE as result. But MFXVideoDECODE_DecodeFrameAsync() returns MFX_ERR_INCOMPATIBLE_VIDEO_PARAM. I invoke, as manual recommend, the MFXVideoDECODE_GetVideoParam(), that returns the same values as previous decoded frame, so, it no need to reallocate my frame buffers. The my next step is reinitialization the DECODE object (invoke MFXVideoDECODE_Init() that returns the MFX_ERR_NONE). Then I "drain" old frames with MFXVideoDECODE_DecodeFrameAsync() with NULL pointer as a first param and continue the decoding loop. The first invoke of MFXVideoDECODE_DecodeFrameAsync() returns MFX_ERR_MORE_DATA and output mfxSyncPoint as NULL, and so on.

On my mind, decoder "thinks", that if the frame has the header (cose MFXVideoDECODE_DecodeHeader() returns the correct result), it is a key frame, try to decode it as a key frame, but, in fact, it is non key frame with header as it's prefix.

Unfortunately I don't know why some cameras make it. The question is - can I detect this situation with Media SDK and decode so frame correctly? Thanks.

[Harshdeep_B_Intel · Accepted solution]

Hi Alex,

From a Media SDK perspective, if you follow the steps described in MediaSDK manual under the "Decoding Procedures" section  and supply data that is not sufficient to decode an entire frame, the DecodeFrameAsync call will return "MFX_ERR_MORE_DATA" and you can send more data until you reach a point in the bitstream that is sufficient. It is recommended that app control header insertion before delivering frames to decoder and you can reposition decoder bitstream to decode frames, I suggest following recommended steps in MediaSDK Developers Guide document "Decoder Bitstream Repositioning" section (chapter 3.4). Hope this is the information you are looking for. 

Thanks,

[Alex_S_16]

Thank you Harsh