DecodeFrameAsync keep return status MFX_WRN_DEVICE_BUSY

[Leo_Z_]

Hi, 

I'm using Intel Media SDK 2015R6 for live transcoding on CentOS 7.1 (Intel(R) Core(TM) i7-5650U CPUs), after a while the function DecodeFrameAsync keep return warning MFX_WRN_DEVICE_BUSY and then it enter an infinite loop，but intel_gpu_top shows the devices was idle and it will be normal when i restart the application.

Best Regards!

[Jeffrey_M_Intel1]

For decoding from network streams, you can try watching the Corrupted flag in mfxFrameData.  If it is nonzero, drain and reset your pipeline.  

By the way, you probably want to use metrics monitor instead of intel_gpu_top.

Please let us know if you still see this problem after adding the drain/reset step.

Regards, Jeff

[Leo_Z_]

Hi Jeffrey,

Thanks for the reply.

I just tried to watch the Corrupted flag in mfxFrameData, it is ZERO as show in my output logs

(dec busy: frame 72074. Corrupted flags: 0.       dec busy: frame 72074. Corrupted flags: 0).

the Corrupted flag shows above is in the input mfxFrameSurface1 of function " MFXVideoDECODE_DecodeFrameAsync ", am i doing right?

and where can i get the "metrics monitor" you metioned, i'm using the sdk provided by artesyn, no such tools.

[Jeffrey_M_Intel1]

Sorry for the delayed reply.  The corrupted flag for the surface output from decode will show zero unless errors are detected in the input.

You probably want to update to the latest MSS release.  It has some new decode robustness features.

The metrics monitor is in /opt/intel/mediasdk/tools/metrics_monitor

[Leo_Z_]

Hi Jeffrey,

Thanks for the reply.

I have confirmed that the problem was caused by packets losing of the source live stream. From what i saw in mfxDecodeStat from function GetDecodeStat(), the NumCachedFrame was keep increase until hit the maximum, and then return decode status MFX_WRN_DEVICE_BUSY, then it enter an infinite loop.

[Jeffrey_M_Intel1]

You may want to try checking the Corrupted field of the frames output by the decoder.  If this is nonzero reset the pipeline.  In the testing we've done this is sufficient to avoid the behaviour you've described for lost/corrupted packets.  If it doesn't for you, any help you can give with detailed info or, even better, code, to reproduce will help us resolve the problem.