Opened 5 months ago

Last modified 5 months ago

#6492 new defect

Intel QSV: "No device available for encoder" message is given

Reported by: alexpigment Owned by:
Priority: important Component: undetermined
Version: unspecified Keywords: qsv, quick sync, intel, h264_qsv
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

As of ~2017-06-15, attempting to use the h264_qsv encoder will result in a message that says "No device available for encoder (device type qsv f or codec h264_qsv)." The encode still occurs, but this is presumably a software fallback. Issue was confirmed on an i7-3770 and an i5-4570S. Tested using Zeranoe Win64 static builds; Build from 2017-06-15 is the first build that exhibits the issue.

How to reproduce:

% ffmpeg -f lavfi -i smptebars -c:v h264_qsv -look_ahead 0 -q:v 10 -r 30000/1001 -t 10 -an 360p1.mp4

ffmpeg version: N-86619-ge9510dc
built on 2017-06-26

Change History (4)

comment:1 Changed 5 months ago by jkqxz

The warning is reflecting that ffmpeg isn't supplying an external device to libavcodec and therefore doesn't really know whether it will use hardware or not. Depending on your setup, it may or may not find a device and use it by default.

Supplying a device explicitly will always remove the warning.

If your default setup is right (the case where it would probably have used hardware anyway), then you can just do:

-init_hw_device qsv:hw

or

-init_hw_device qsv:sw

(Try those and compare the speed to find out whether your original command used hardware or not.)

In a trickier case you might want something like:

-init_hw_device vaapi:/dev/dri/renderD129 -init_hw_device qsv@vaapi0

in order to pick the right subdevice (this sort of case never worked by default).

comment:2 Changed 5 months ago by alexpigment

When I specify either -init_hw_device qsv:hw or qsv:sw , I get the following message:

[AVHWDeviceContext @ 025d8b00] Error initializing an MFX session: -3.
Device creation failed: -1313558101.
Failed to set value 'qsv:hw' for option 'init_hw_device': Unknown error occurred

Error parsing global options: Unknown error occurred

For what it's worth, this is on Windows on a system with both Nvidia and Intel cards enabled (a monitor is hooked into each to allow testing of NVENC and QSV simultaneously).

Curiously, I tested on two systems with *only* Intel graphics, and specifying -init_hw_device qsv:hw processed without error. Specifying -init_hw_device qsv:sw would produce the same "Error initializing an MFX session" error.

I did some benchmarks and it seems that the speed is roughly equivalent between specifying "-init_hw_device qsv:hw" and not specifying anything.


So if I reevaluate the problem, here are my findings:

1) "No device available for encoder (device typo qsv for codec h264_qsv)" message is being specified for any system (that I've tested, at least) since 2017-06-15.

2) Specifying -init_hw_device qsv:hw will make the message/warning above go away for systems with only Intel graphics (and seemingly will produce identical videos).

3) Specifying -init_hw_device qsv:hw will produce the following terminal error on systems with both Nvidia and Intel graphics:

[AVHWDeviceContext @ 025d8b00] Error initializing an MFX session: -3.
Device creation failed: -1313558101.
Failed to set value 'qsv:hw' for option 'init_hw_device': Unknown error occurred

Error parsing global options: Unknown error occurred

4) Specifying -init_hw_device qsv:sw will produce the following terminal error on any system tested:

[AVHWDeviceContext @ 025d8b00] Error initializing an MFX session: -3.
Device creation failed: -1313558101.
Failed to set value 'qsv:sw' for option 'init_hw_device': Unknown error occurred

Error parsing global options: Unknown error occurred

5) Specifying either "-init_hw_device qsv:hw" or "-init_sw_device qsv:sw" on any build prior to 2017-06-15 will produce the following unrecognized option error:

Unrecognized option 'init_hw_device'.
Error splitting the argument list: Option not found

I guess I'm not entirely sure what the point of the change was on 2017-06-15.

comment:3 Changed 5 months ago by jkqxz

Sounds like you have a complex case for which we don't know the device but is working by internal automagic inside libmfx (assuming it actually did use hardware before).

To explicitly make the device on Windows when multiple are present, you want something like:

-init_hw_device dxva2=intel:N -init_hw_device qsv@intel

where N is the index of the Intel graphics adapter for D3D9.

Note that if you do not change any options then nothing has changed other than the appearance of the warning. The warning is telling you that it may not be working with hardware (though apparently it is anyway in your setup by automagic inside the driver; it is just a warning after all) and that if you do anything trickier then it probably won't work because we don't know the device.

comment:4 Changed 5 months ago by alexpigment

I'm not trying to be dense here, but isn't it less than ideal to show a warning for people who don't specify a card explicitly, especially given that most people have a single graphics card in their computer? I would think that an important part of QSV adoption in FFMPEG is not requiring the user to look up cryptic command parameters like "-init_hw_device" when no other encoder (NVENC) requires them to use such options. If the behavior stays as it is, I suspect that this will be one of those things where people will google the warning and there are forum posts saying "just ignore it. it always says that". Just my two cents, of course.

Note: See TracTickets for help on using tickets.