Necessary to drain prior to calling MFXVideoDECODE_Close when decoding?

[AaronL]

Is it necessary to drain any outstanding frames prior to calling MFXVideoDECODE_Close()?  All the SDK decoder samples drain before calling MFXVideoDECODE_Close(), but perhaps in all of these cases, the remaining frames (after hitting end of frame) are all of significance.  However, in my application, after a certain point, I don't need to do anything with any remaining frames in the decoder object, and if possible, I'd like to discard them quickly by using MFXVideoDECODE_Close() without draining first.

Is it safe to do this?  The SDK documentation is unclear on this.

[Surbhi_M_Intel]

Hi Aaron, 

Yes, it is necessary to drain the loop before calling the decode close function. Once the bitstream is done, frames may be still be in the decoder since it's asynchronous pipeline, so additional loop with NULL parameter is required. If you do not drain the loop,you will miss the last few frames which were still in the decoder. So it is important to drain the loop and clear the buffer. 
The certain point of time in your application is always not close to end of the stream and are you decoding some extra frames so that your decoder decodes until the point you need the frames to be? It really depends upon your application but in general I won't consider this to be safe by not choosing to have a drain loop. 

Thanks,
Surbhi

[AaronL]

For draining, is it enough to just call DecodeFrameAsync() repeatedly till it returns MFX_ERR_MORE_DATA, or do I also need to call SyncOperation() for each successful call to DecodeFrameAsync() as well?  I definitely don't need the surface content at the point that I would drain, so I'd rather not take the cost of doing SyncOperation() calls if I can avoid it.  My application involves streaming (decoder on server side, encoder on client side), and at a certain point, the streaming session ends, and there is no way to know ahead of time when this will happen.  When the streaming session ends, I no longer have need of any outstanding frames that may be traversing the asynchronous pipeline.

Thanks, Aaron

[AaronL]

After an additional review of the SDK API Reference Manual, I think that it is clear that it isn't necessary to drain prior to calling Close().  In the Multiple Sequence Headers section of the document, it states the following:

"The MFXVideoDECODE_DecodeFrameAsync function returns MFX_ERR_INCOMPATIBLE_VIDEO_PARAM if the decoder parsed a new sequence header in the bitstream and decoding cannot continue without reallocating frame buffers. The bitstream pointer moves to the first bit of the new sequence header. The application must do the following:

1. Retrieve any remaining frames by calling MFXVideoDECODE_DecodeFrameAsync with a NULL input bitstream pointer until the function returns MFX_ERR_MORE_DATA. This step is not necessary if the application plans to discard any remaining frames.

2. De-initialize the decoder by calling the MFXVideoDECODE_Close function, and restart the decoding procedure from the new bitstream position.

This clearly demonstrates that it is safe to call Close() without draining first.

[Surbhi_M_Intel]

Thanks for the details! Yes, if you don't need last frames, which I believe is the certain point in your application you don't need to drain or sync again. It wasn't clear from your first post but great you got the answer to it. 

-Surbhi