VAAPI: Allow software fallback to be disabled on command-line

[U. Artie Eoff]

Summary of the bug:

Occasionally regressions get introduced into vaapi drivers that cause vaapi hwaccel initialization to fail. When this happens, ffmpeg will fallback to software mode automatically without any specific log/output indicating it has done so. There are many points of potential failure in hwaccel initialization with varying log/output messages to give you clues. Given the varying error messages, this makes it very difficult and impractical for any type of automation to detect when hwaccel fails (e.g. an automated regression test suite for hwaccel verification).

To effectively detect when SW fallback occurs, a specific log/output message that indicates this has happened should be emitted at minimum.

Preferably, a command-line option for ffmpeg to disable software fallback would be better.

How to reproduce:

Using the following software stack (intel-media-driver has bug at this point):

libva (master) heads/master-0-g285267586a3d ​https://github.com/01org/libva
gmmlib (master) heads/master-0-g3e602a84dccd ​https://github.com/intel/gmmlib
intel-media-driver (master) heads/master-0-gb1705b29ca3a ​https://github.com/intel/media-driver
msdk (master) heads/master-0-g3c6acdeb2f71 ​https://github.com/Intel-Media-SDK/MediaSDK
ffmpeg (master) heads/master-0-g156120fcf8fa ​https://git.ffmpeg.org/ffmpeg

% LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel vaapi \
  -hwaccel_device /dev/dri/renderD128 -i input.jpg \
  -pix_fmt yuv420p -f rawvideo -vsync passthrough \
  -y output.yuv

ffmpeg version N-92257-g156120fcf8fa Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 8 (GCC)
  configuration: --disable-static --enable-shared --enable-libdrm --enable-vaapi --enable-libmfx --disable-amf --disable-audiotoolbox --disable-cuda --disable-cuda-sdk --disable-cuvid --disable-d3d11va --disable-dxva2 --disable-libnpp --disable-mmal --disable-nvdec --disable-nvenc --disable-omx --disable-omx-rpi --disable-rkmpp --disable-v4l2-m2m --disable-vdpau --disable-videotoolbox --enable-nonfree --enable-gpl
  libavutil      56. 20.100 / 56. 20.100
  libavcodec     58. 33.102 / 58. 33.102
  libavformat    58. 19.102 / 58. 19.102
  libavdevice    58.  4.106 / 58.  4.106
  libavfilter     7. 37.100 /  7. 37.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
[mjpeg @ 0x22403c0] Format mjpeg detected only with low score of 25, misdetection possible!
Input #0, mjpeg, from '/home/ffmpeg/input.jpg':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 25 tbr, 1200k tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg (native) -> rawvideo (native))
Press [q] to stop, [?] for help
[mjpeg @ 0x22437c0] Failed to create decode configuration: 18 (invalid parameter).
[mjpeg @ 0x22437c0] Failed setup for format vaapi_vld: hwaccel initialisation returned error.
[swscaler @ 0x2314040] deprecated pixel format used, make sure you did set range correctly
Output #0, rawvideo, to 'test.yuv':
  Metadata:
    encoder         : Lavf58.19.102
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 622080 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.33.102 rawvideo
frame=    5 fps=0.0 q=-0.0 Lsize=   15188kB time=00:00:00.20 bitrate=622080.0kbits/s speed=3.33x    
video:15188kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

[jkqxz]

From the libavcodec perspective this is already present - just refuse to return anything other than your chosen format in the get_format() callback, and fail if it isn't offered.

In terms of the ffmpeg utility, I guess it would make sense to have an override option to avoid get_format() making any choice other than the one you want - currently it will go through all usable (i.e. not requiring hardware resources it doesn't have) choices until one of them works.

[Linjie.Fu]

Provided a patch to return directly if the hardware init fails.

This solution is less common but valid in the software callback condition due to the failure of hardware init.

patchwork: ​https://patchwork.ffmpeg.org/patch/10846/
mail list: ​http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235780.html
commit id: b3f1ffde35bf36f66af8f711adbf1da605ffb287

[U. Artie Eoff]

Latest proposal is at ​https://patchwork.ffmpeg.org/patch/11015/

Is that patch ready to be merged yet?