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.

Weird MFXClose problem - one machine only!

Cetrini__Fabio
681 Views

Hi all, I'm facing a very uncommon issue with ONE of our test machine.

We are extensively testing our video solution, recently integrated with Intel hardware decoding capabilities (2018 R2.1 media sdk).

So, only on one of our test machine, the problem appears when we stop the video stream and the code execution hits the MFXClose code line: this operation takes 1 second to be executed on that machine!

Let me explain better: the stop procedure takes a bunch of milliseconds to perform GStreamer deallocation, MFXVideoDECODE_DecodeFrameAsync freeing loop, MFXVideoDECODE_Close, textures freeing and so on. Then it brakes 1 second at the MFXClose.

We are testing on a wide range of machine, no other machine presenting that issue, even my 8-years old 2nd gen i7 notebook works as expected.

These are the hardware spec. It'a an ACER Veriton S2660G desktop, i7-8700@3.2GHz cpu, 16GB memory.

Motherboard chipset is Intel Cannon Point B360, coffee lake-s

Integrated graphics is UHD630 with latest availble drivers (26.20.100.7985)

Intel utility reports device ID 3E92 and device Revision 00, Shader version 5.1, OpenCL versione 2.1, Vulkan 1.2.131 and Graphics Output Protocolo 9.0.1085.

Of course Windows 10 latest version with all patches installed.

We even updated motherboard bios and tested another ram module, without any improvement.

 

 

Is that some sort of hardware incompatibility?

0 Kudos
1 Solution
Cetrini__Fabio
681 Views

Hi Mark, thank you for your reply.

No, the sample app actually does not replicate the issue, but I'm understanding better by trial on mine.

This is my "Stop" procedure, in the original order:

  • empty bitstream decode loop
  • MFXVideoDECODE_Close
  • free mfxFrameSurfaces
  • free mfxFrameAllocator
  • free bitstream and otherr "calloc" pointers
  • release D3D Textures
  • MFXClose

If I swap the last two blocks, that machine executes MFXClose in 10 msec as expected!

These are the textures I pass to the decoder in the FrameAllocator_GetHDL callback, how this could be related with the delay?

Thank you

Fabio Cetrini

 

View solution in original post

0 Kudos
2 Replies
Mark_L_Intel1
Moderator
681 Views

Hi Fabio,

Sorry for the late response, can you run the Media SDK sample with the similar functions? You can modify the sample so it has the same logic sequence as your application and see if you got the same problem in MFXClose function.

The other check is, if this problem is only on this machine or this type of machine. You can try to run the application on two devices with the same type.

Mark Liu

0 Kudos
Cetrini__Fabio
682 Views

Hi Mark, thank you for your reply.

No, the sample app actually does not replicate the issue, but I'm understanding better by trial on mine.

This is my "Stop" procedure, in the original order:

  • empty bitstream decode loop
  • MFXVideoDECODE_Close
  • free mfxFrameSurfaces
  • free mfxFrameAllocator
  • free bitstream and otherr "calloc" pointers
  • release D3D Textures
  • MFXClose

If I swap the last two blocks, that machine executes MFXClose in 10 msec as expected!

These are the textures I pass to the decoder in the FrameAllocator_GetHDL callback, how this could be related with the delay?

Thank you

Fabio Cetrini

 

0 Kudos
Reply