Intermittently, encoding video with h264 Quick Sync can fail with 'EncodeFrameAsync returned -17'

[mikes]

Summary of the bug:
When encoding video with the h264 Quick Sync encoder, sometimes an error gets returned that reads "EncodeFrameAsync returned -17".
I believe that -17 is the Intel error code "MFX_ERR_DEVICE_FAILED". I've reproduced the error with many different images sizes, but it was easy enough to reproduce the problem with a 256x256 image size.
The input data is irrelevant, so the test.avi just has green images. I've attached it anyway, so the test can be repeated exactly as I have performed it.

This test was run on my Windows 7 64-bit machine with Quick Sync Hardware Version 5 (Skylake). My Windows 10 64-bit machine with Quick Sync Hardware Version 3 (Haswell) will also fail running this test, but instead of returning the -17 error, it simply hangs.

My test.avi has 1000 frames, and many times the encoding will be successful. You may need to run the test several times before seeing this error.

How to reproduce:

% ffmpeg -i test.avi -pix_fmt nv12 -g 0 -r 30 -b:v 400k -vcodec h264_qsv test_out.avi -report
ffmpeg version [From ffmpeg Snapshot last modified time 2016-07-12 19:22]
built on July 13, 2016

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[mikes]

ffmpeg report error log

[mikes]

Test AVI file

[ctetrick]

I have also encountered this error. I have never seen this on a Windows 7 x64 machine. Until now I had thought this was a Windows 10 only problem, though on one machine it never occurred with Windows 7, it did after installing Windows 10. that was a Haswell machine (i7-4790S @ 3.20 Ghz) with only an Intel GPU. I've also seen it on my Windows 10 x64 machine with an i7-4790 @4.00 Ghz, nVidia 970 and 32Gb ram. the most important difference being an outboard GPU.

Also, FWIW I have seen this on very recent builds from the Zeranoe site as well as my own builds.

I've seen the 'hang' on Windows 10 as well. In this case it was with the default Intel Graphics driver installed with Windows. When this happens MFX_EncodeFrameAsync returns MFX_WRN_DEVICE_BUSY forever. In my own build I added a timeout and treat it as an error.

I also concur that the input doesn't seem to matter, although I see it more at 1920x1080.
I've also tried a number of variations in rate control and other adjustments, but none seem to matter.

[ctetrick]

intel tracer log - successful encode

[ctetrick]

intel tracer log - failed encode

[ctetrick]

I've added a couple of trace logs. The second shows a typical failure.
The failure seems to occur just before the time that the queue would get full enough to call MFXVideoCORE_SyncOperation() where it would output the first part of the bitstream.

[Zyoma108]

any changes?

[Carl Eugen Hoyos]

Was the issue fixed in current FFmpeg git head?

[Carl Eugen Hoyos]

Please reopen if this is still reproducible.

[Zyoma108]

Still reproducible

[mikes]

The problem stopped occurring for me when I updated to the latest Intel® Graphics Driver (version 15.45.10.4542). Hopefully this will work for others as well.

[Carl Eugen Hoyos]

Thank you for testing again!

[Aman]

I'm still seeing this issue on recent zeranoe builds (20170921-183fd30), on a variety of windows computers that are all running the latest Intel Graphics drivers.

I haven't been able to track down the issue yet since it's very intermittent. Running the same command over and over, the encoder will fail atleast half the time.

[Aman]

I have two computers running Windows 10.

The first does not reproduce this issue. It's an Intel Celeron J1800 with v10.18.10.4425 of the Intel HD Graphics driver.

The second computer reproduces this issue very often. It is an Intel Celeron N3450 with v22.20.16.4771 of the Intel HD Graphics driver.

(I've also observed this behavior previously on several machines, including one with a i5-4570).

I'm using the following command, with the attached sample2.mpg and the 20170921-183fd30 build from ffmpeg.zeranoe.com:

ffmpeg.exe -hide_banner -loglevel warning -t 5 -i sample2.mpg -vf yadif -profile:v high -level 42 -g 60 -b:v 6000k -minrate 5400k -maxrate 6600k -bufsize 12000k -c:v h264_qsv -an -y -f mpegts nul -stats

The command will succeed 6 times out of 10:

DriverDDIMain = 947
DriverDDIMain10 = 947
DriverDDIMainLP = 966
DriverDDIMain10LP = 966
frame=    6 fps=0.0 q=-0.0 Lsize=     174kB time=00:00:00.20 bitrate=7129.0kbits/s speed=0.262x

And the rest of the time it will fail:

DriverDDIMain = 947
DriverDDIMain10 = 947
DriverDDIMainLP = 966
DriverDDIMain10LP = 966
[h264_qsv @ 000000000061b520] Error during encoding: device failed (-17)
Video encoding failed

[Aman]

I was also able to reproduce on a Windows 10 Pro machine with an i5-6600K, running the same version of the driver as the other computer that shows the problem (v22.20.16.4771 Intel HD Graphics 530).

And again on an i7-5557U running both v20.19.15.4531 and v20.19.15.4624

[Aman]

Reproduced again on an i3-4130 running Windows 10 Pro, with both v20.19.15.4531 (dated 9/29/2016) and v20.19.15.4703 (dated 6/9/2017).

[Aman]

I did some googling to see how other mfx consumers deal with these errors.

VLC calls MFXVideoENCODE_Reset() when it receives MFX_ERR_DEVICE_FAILED
​https://github.com/videolan/vlc/blob/d139d48a55fdf1d1a59d354d354f552a589efa25/modules/codec/qsv.c#L716-L718

QSVEnc calls Close() and Init() again on MFX_ERR_DEVICE_{FAILED,LOST}
​https://github.com/rigaya/QSVEnc/blob/b3b998c81fd2c47fb1e3619e635d6296f29af849/QSVEncC/QSVEncC.cpp#L3511-L3518

[Aman]

Documentation from Intel also recommends reinitializing the MFX session when getting a device failed error: ​https://software.intel.com/en-us/node/628427

[Maxym Dmytrychenko]

please check if still valid with latest driver from ​https://downloadcenter.intel.com/download/27780/Graphics-Intel-Graphics-Driver-for-Windows-15-40-?product=97500

[Maxym Dmytrychenko]

should be fixed after commit 14fe81b3a88dfe4dbac12e8715f9a3f05b5ef1bf