Opened 3 weeks ago

Last modified 8 days ago

#7511 new enhancement

FFmpeg Windows version with QSV hwaccel fails over TERMINAL

Reported by: msiders Owned by:
Priority: wish Component: avcodec
Version: git-master Keywords: qsv
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:
How to reproduce:

 ffmpeg.exe -hwaccel qsv -c:v h264_qsv -i file.ts -filter_complex "[i:256]deinterlace_qsv,scale_qsv=720:576[out]" -map [out] -map i:257 -c:0 h264_qsv -preset medium -c:1 copy -f mpegts output.ts

The privious command executed in Windows, reads one MPEG-TS file with one video stream (pid 256) and one audio stream (pid 257). The filter graph deinterlaces the input video (H.264 1080i content) and downscale to PAL size. Then it compress it using default settings in H.264 with the hardware encoder. All is done in the GPU.

OK, this works... when executed inside a COMMAND TERMINAL in a Windows session (even over RDP remote connections).

However, when executing identical command inside a OpenSSH session this error appears:

[AVHWDeviceContext @ 000002914a559000] Failed to create Direct3D device
Error creating a QSV device
qsv hwaccel requested for input stream #0:0, but cannot be initialized.
Error while decoding stream #0:0: Operation not permitted

The OpenSSH session used is the STANDARD from Microsoft for Windows 10. So no 3rd party or experimental code is used.

I'm not sure if this can be fixed. But I report it here as using the CUVID hwaccel for NVIDIA it works as expected inside the same TERMINAL.

I hope this will be fixed sometime.

Change History (6)

comment:1 Changed 3 weeks ago by heleppkes

QSV currently uses D3D9. For full headless operation, D3D11 would be required. I do not know if its fully compatible with that yet.

CUVID on the other hand can natively work headless (ie. through CUDA), and NVENC encoding also with D3D11, so its more flexible in that regard.

Last edited 3 weeks ago by heleppkes (previous) (diff)

comment:2 Changed 3 weeks ago by msiders

Hi heleppkes,

Thank you for the response! ;)

So the problem is the D3D9 use instead of D3D11 for the QSV accelerator?
If yes, then I hope someone can upgrade the code. Or if this is impossible, then that Intel will upgrade his library for DX11 support.

Any idea about it?

comment:3 Changed 3 weeks ago by msiders


Regarding the use of D3D11 or D3D9 with the QSV accelator I noted this:

So I figure that the hwcontext for QSV needs to add support for handles with D3D11. Then the offscreen processing will be available.

I'm right?

comment:4 Changed 3 weeks ago by msiders


I found specific information in offical documentation from Intel:

In section "4.18.1 Muti-GPU and “headless” configurations" indicates:

Applications wishing to leverage the Intel Media SDK’s hardware acceleration library
when a discrete card is the primary device, or on devices without a monitor attached –
such as “Session 0” modes, are required to initialize the Intel Media SDK to utilize the
DirectX11 infrastructure, as well as provide its own memory allocation routines that
manage DirectX 11 surfaces.

So, the solution seems to include a new parameter when initializing the QSV context to select D3D11 when calling to MFXInit().

What you think?

comment:5 Changed 8 days ago by msiders


I need help to overcome this problem. I really need to use the *_QSV filters offscreen.
So, any idea to move from D3D9 to D3D11 with the QSV context?

comment:6 Changed 8 days ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords qsv added
  • Priority changed from normal to wish
  • Type changed from defect to enhancement
Note: See TracTickets for help on using tickets.