Media (Intel® Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools like Intel® oneAPI Video Processing Library and Intel® Media SDK
Announcements
The Intel Media SDK project is no longer active. For continued support and access to new features, Intel Media SDK users are encouraged to read the transition guide on upgrading from Intel® Media SDK to Intel® Video Processing Library (VPL), and to move to VPL as soon as possible.
For more information, see the VPL website.
3062 Discussions

Necessary to drain prior to calling MFXVideoDECODE_Close when decoding?

AaronL
Beginner
327 Views

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.

0 Kudos
4 Replies
Surbhi_M_Intel
Employee
327 Views

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

0 Kudos
AaronL
Beginner
327 Views

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

0 Kudos
AaronL
Beginner
327 Views

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.

0 Kudos
Surbhi_M_Intel
Employee
327 Views

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
 

0 Kudos
Reply