MFXEnumImplementations() fails on non-logged in Windows or old processors

[nyanmisaka]

With the support of VPL in FFmpeg 6+ and the deprecation of MSDK, we switched to using VPL loader to compile FFmpeg. But this has caused some problems on Windows. Our use case is a media server, so an interactive desktop environment is not required.

• Some users with i7-13700H / Xe Graphics reporting that QSV transcoding in FFmpeg reports MFX_ERR_NOT_FOUND: -9 errors when no user is logged into Windows. https://github.com/intel/cartwheel-ffmpeg/issues/334

  [AVHWDeviceContext @ 000002533d2eacc0] Using device 8086:a7a0 (Intel(R) Iris(R) Xe Graphics).
  [AVHWDeviceContext @ 000002533b7aa300] Error creating a MFX session: -9.

• Another user with a very old Haswell / HD 4600 processor also reported the same MFX_ERR_NOT_FOUND: -9 error. (I mention this because VPL loader also claims backward compatibility with the MSDK runtime) https://github.com/jellyfin/jellyfin/issues/12694

  [AVHWDeviceContext @ 00000173d61a79c0] Using device 8086:0412 (Intel(R) HD Graphics 4600).
  [AVHWDeviceContext @ 00000173d6225440] Error creating a MFX session: -9.

I traced the code in FFmpeg and found that it was MFXEnumImplementations() that did not find any impl and returned this error code, which is a function newly introduced in VPL loader. If we switch back to compiling FFmpeg with MSDK, users report that everything works fine.

In both cases, is this expected behavior in VPL, or is it a new issue? Thanks in advance.

[grabbel]

Unfortunately i get the same error running ffmpeg 6+ on a HD4600 with Hardware acceleration on windows.

[AVHWDeviceContext @ 0000021b7437b340] Using device 8086:0412 (Intel(R) HD Graphics 4600).

[AVHWDeviceContext @ 0000021b72d0b480] Error creating a MFX session: -9.

Device creation failed: -1313558101.

Failed to set value 'qsv=qs@dx11' for option 'init_hw_device': Unknown error occurred

Error parsing global options: Unknown error occurred

[jonrecker]

Thank you for the info. Haswell is not included in the current VPL support matrix (more info here) but as you noted may be loaded via MSDK.

We've not been able to reproduce the issue of running in a headless environment. If you run vpl-inspect in both scenarios, it will report all available VPL implementations. FFmpeg also applies multiple filters using MFXSetConfigFilterProperty(), and if none of the reported implementations match those filters then VPL will return MFX_ERR_NOT_FOUND.

[nyanmisaka]

Thank you for the info. Haswell is not included in the current VPL support matrix (more info here) but as you noted may be loaded via MSDK.

We've not been able to reproduce the issue of running in a headless environment. If you run vpl-inspect in both scenarios, it will report all available VPL implementations. FFmpeg also applies multiple filters using MFXSetConfigFilterProperty(), and if none of the reported implementations match those filters then VPL will return MFX_ERR_NOT_FOUND.

@jonrecker This is reported by our users. I also cannot reproduce the first problem on ARC GPU. But users confirmed that using MFXInit() / MFXInitEx() can fix this problem in their environment.

Therefore we added a patch in our FFmpeg to try to fallback to using MFXInit() when VPL initialization fails.

But I am not sure whether these deprecated functions will be removed soon. If not, can Intel's FFmpeg developers also submit similar patches upstream to alleviate the issue and avoid us maintaining two FFmpeg versions containing VPL and MSDK separately?

[jonrecker]

@nyanmisaka The functions marked deprecated are not expected to be removed until the next major version update (API 3.0). So MFXInit/Ex() will probably remain in the API for the foreseeable future.

[nyanmisaka]

@nyanmisaka The functions marked deprecated are not expected to be removed until the next major version update (API 3.0). So MFXInit/Ex() will probably remain in the API for the foreseeable future.

Thx for the info. So I think I'll keep this patch to resolve the issue.