You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CPU: i7-13700H
GPU: Xe integrated graphics on the CPU
GPU Driver: 31.0.101.5379/31.0.101.5590/31.0.101.5535
OS: Windows 11 Professional Edition
According to user reports, when using VPL loader (FFmpeg 6+) instead of MSDK loader (FFmpeg 5), the user must log in to Windows to initialize the QSV device, for example log in with the Windows RDP.
But once the user closes RDP or logs out, the VPL loader will not find the device and return MFX_ERR_NOT_FOUND: -9 error.
Strangely, the D3D11 device has been initialized successfully, but the QSV device cannot be derived from it.
# ffmpeg -init_hw_device d3d11va=dx11:,vendor_id=0x8086 -init_hw_device qsv=qs@dx11
[AVHWDeviceContext @ 000002533d2eacc0] Using device 8086:a7a0 (Intel(R) Iris(R) Xe Graphics).
[AVHWDeviceContext @ 000002533b7aa300] 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
I couldn't reproduce this issue on my windows 11 home edition with CPU i7-1165G7 after log out and SSH to it by using another machine.
What if you run vpl-inspect -ex on your environment? They have samilar initialization. If the issue is still there, you can report it to libVPL.
According to user reports, when using VPL loader (FFmpeg 6+) instead of MSDK loader (FFmpeg 5), the user must log in to Windows to initialize the QSV device, for example log in with the Windows RDP.
But once the user closes RDP or logs out, the VPL loader will not find the device and return
MFX_ERR_NOT_FOUND: -9
error.Strangely, the D3D11 device has been initialized successfully, but the QSV device cannot be derived from it.
https://github.com/FFmpeg/FFmpeg/blob/0b67c83b2eadf6350587ae7c4a63a8f9bba67cae/libavutil/hwcontext_qsv.c#L1179-L1284
Apparently the VPL loader takes a more complex approach
mfxLoader + MFXEnumImplementations
to filtering devices, which I think may be the cause of the problem. Because there is no problem when running the old code path in the MSDK loader in the same environment.This usage scenario is a headless server. Is this expected behavior or is it an issue? Thanks in advance.
The text was updated successfully, but these errors were encountered: