I have video editing application and using Intel MSDK 2017.0.1 for decoding the frames (Hardware acceleration). I have my own demuxer that is actually feeding encoded bits to decoder. I know that my demuxer/splitter can provide the input bitstream as one complete frame of data, less than one frame (a partial frame), or multiple frames.
I want to weigh two options here :
1) Providing only single frame of encoded data to the decoder and asking decoder to return me the single frame. This I have achieved by setting AsyncDepth Bit to one and setting MFX_STREAM_COMPLETE_FRAME data flag in mfxBS. Please note that for this DecodeFrameAsync API was returning MFX_ERR_MORE_DATA first time I call with single frame of encoded data and then I had to explicit call DecodeFrameAsync with NULL as BS input, then decoder returned me MFX_ERR_NONE and then I fetched the decoded frame.
2) Second option is to provide the decoder as much input encoded data it is asking and let it buffer internally and finally calling SyncOperation once DecodeFrameAsync API returns MFX_ERR_NONE.
I want to know when to use which option. In what scenarios I should use the first and when I should use the approach second?
when feeding NULL as BS input you are effectively signalling the end of the bitstream and that you want to drain the remaining frames.
So, your option 2 would be the suggested normal operation for the decoder. And option 1 the finalization step.
Hope that helps,
Understood. But what I am asking is that if I design my system such that it always take one frame of data at a time and feed it to decoder and fetch the frame and I do it for every frame that I need to decode. This would mean passing NULL as mfxBS when decoder ask for more data because I want to do it for a single frame at a time. Do you see any issues with this approach?
Second approach would be like feed the decoder as much data as it ask and on MFX_ERR_NONE fetch the frame.