How to unlock mfxFrameSurface1 after decode

[mmulh]

OneVPL version 1.35, CPU i5-6500.

I'm trying to figure out the behavior of mfxFrameSurface1.Data.Locked.

If I make a call to MFXVideoVPP_RunFrameVPPAsync(session, in, out, ...) the locks work as I expect - ex. for my in/out locks, before the call they might be 1, 0; immediately after the call they would be 2,1 (since both in/out surfaces are being used), and then if I sync the out frame,  the locks are back to 1,0.

I call MFXVideoDECODE_DecodeFrameAsync which increments the lock on the output frame.  If I sync the output frame, the lock is still held for some reason.  If I run a VPP transform on the frame, the output frame is still locked.  If I call MFXVideoENCODE_EncodeFrameAsync, it will increment the lock, and after a sync will double decrement the lock - I'm assuming once from the encode operation, and the second for the lock acquired on the decode.

The issue is that sometimes I will NOT do the encode.  The frame seems to be truly locked, because if I clear the lock myself, the frame seems unusable in a subsequent decode.  On windows, the stack seems to eventually release these frames, however on linux the frames do get released eventually as well however my memory usage climbs rapidly - which MAY be related to the lock still being held. So how do I release/unlock this frame (remove the lock that was set by the decode) if I'm not running a subsequent encode?

[DiyaN_Intel]

Hi, 

Good day to you.

Thank you for posting in Intel Communities.

Could you please share the following details- 

1. Sample reproducer code.

2. oneVPL version.

3. Exact steps and the commands used.

4. OS and Processor details.

Thanks and regards,

Diya

[DiyaN_Intel · Accepted solution]

Hi, 

Please refer to these two links for a detailed understanding of how to unlock mfxFrameSurface1 after decoding:

1. This link shows simple procedures for oneVPL decode.

2. This link shows two approaches for frame surface management.

If this resolves your issue, make sure to accept this as a solution.

This would help others with similar issues. Thank you! 

Thanks and regards,

Diya

[mmulh]

Okay, the frame surface management document was helpful, thanks.  I'm using the legacy approach since my software needs to run on pre-11th-gen hardware, which doesn't seem to support API version 2.0.  I'm assuming that the behavior I'm seeing is camera specific - that the decoder is keeping all of the "recent" frames locked since they MAY be used as reference frames.

I raised this question because I've got a Windows and Linux variant of the same code (mostly, other than the hardware buffer code).  Both work fine except that I've got an apparent memory leak on the Linux.

Using the legacy approach, is it possible that the stack can still cache frames internally ?  And if so, it there a way to determine how many internal frames are being held ?

[DiyaN_Intel]

Hi , 

Good day to you.

>>Using the legacy approach, is it possible that the stack can still cache frames internally?

Yes, input bitstream and output frames are cached internally.  

>>And if so, is there a way to determine how many internal frames are being held?

The basic theory of operation is that decode can be called multiple times with no input to drain cached decoded frames.  

The MFXVideoDECODE_GetDecodeStat function provides some info about cached frames, but the state machine loop we show in our example code is more generally used.

As with many media APIs, there are a lot of corner cases to consider for decoding. We will keep this feedback in mind for future documentation improvements.

As we can see you have accepted as a solution. Can you please confirm whether we can go forward and close the case?

Thanks and regards, 

Diya

[mmulh]

I'm fine with closing the case, thanks for the information.

[DiyaN_Intel]

Hi, 

Good day to you.

Glad to know that your issue is resolved.

Thanks for accepting it as a solution.

This thread will no longer be monitored by Intel. 

If you need further assistance, please post a new question.

Thanks and regards,

Diya