Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#7933 closed defect (duplicate)

Intel QSV Windows init

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


I have found that ffmpeg qsv encoder command line
ffmpeg -i input.mp4 -b:v 10000k -vcodec h264_qsv -preset fast output.mp4
may throw: "Error initializing an internal MFX session: unsupported (-3)" message on "windows" box configuration.
(first noticed on ffmpeg 4.0.2 but recent master build also suffers from with problem).
OBS-Studio+QSV works without problem on same machine.

By using several test machines(4 different windows boxes) i narrowed the circle of suspects and here is repro:

  • windows 10 x64 1809
  • internal intel graphics enabled in bios (windows driver intstalled) but monitor is not connected
  • discrete graphics card enabled and multiple monitors (>=2) connected

OBS works, ffmpeg fails
If only one monitor is connected to discrete card then ffmpeg starting to work.

So i digged in source comparision cause OBS-studio and ffmpeg depending on same libmfx (but different version).

ffmpeg uses this piece of code:

mfxVersion ver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
ret = MFXInit(impl, &ver, session);


mfxVersion ver = {{0 , 1}};
sts = MFXInit(impl, &ver, &session);

if (sts == MFX_ERR_NONE) {
} else {

sts = MFXInit(impl, &ver, &session);
if (sts == MFX_ERR_NONE) {


OBS force mfx to use HW implementation with "manual" fallback from dx11 to dx9.
I have changed ffmpeg to use OBS technique and it starts to initialize even multiple monitors were connected.

For some completely unknown reason MFXInit(MFX_IMPL_AUTO_ANY ...) call fails with multi monitor config.
It might be releated to some libmfx bug, but OBS-Studio implementation did not triggers it.
So it would be nice if FFmpeg adopts this technique (by adding option to force HW DX11 or/and DX9 QSV implementation)

Change History (5)

comment:1 by Anton Torp, 4 years ago


I feel this is related to ticket 7511

I suggest to provide a method to leave to the user the option for manually selecting which type of surfaces to use: D3D9 or D3D11. This will solve this problem in all scenarios. Even it will be preferable to automatically first try with D3D11 and after try D3D9 if the first fails.


in reply to:  1 comment:2 by ajax16384, 4 years ago


Thanks for response. Unfortunately recipe from related ticket gives same error:
ffmpeg.exe -init_hw_device d3d11va=qsv:MFX_IMPL_hw_any -hwaccel qsv -filter_hw_device qsv -i input.mp4 -vcodec h264_qsv -preset medium output.mp4

ffmpeg version N-94324-g806ac7da69 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9.1.1 (GCC) 20190716
[AVHWDeviceContext @ 00000242e8610c80] Using device 10de:1c02 (NVIDIA GeForce GTX 1060 3GB).
[h264_qsv @ 00000242e8646cc0] Error initializing an internal MFX session: unsupported (-3)
Error initializing output stream 0:0 -- Error while opening encoder for output stream

Test box has window 10 1903 with nvidia and intel adapter. Three monitors connected to nvidia adapter.


Replying to atorp:

comment:3 by Øystein Krog, 4 years ago

I can confirm that the proposed changes work. Here is our fork with the added changes:

comment:4 by Hendrik, 4 years ago

Resolution: duplicate
Status: newclosed

As hinted in the first comment, this ticket is indeed a duplicate of #7511

Last edited 4 years ago by Hendrik (previous) (diff)

comment:5 by Carl Eugen Hoyos, 4 years ago

Version: 4.0.3git-master
Note: See TracTickets for help on using tickets.