Opened 6 years ago

Last modified 6 years ago

#7519 new enhancement

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

Reported by: U. Artie Eoff Owned by:
Priority: wish Component: ffmpeg
Version: unspecified Keywords: vaapi
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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%

Change History (4)

comment:1 by Carl Eugen Hoyos, 6 years ago

Component: ffmpegundetermined
Keywords: vaapi added
Priority: importantwish

comment:2 by jkqxz, 6 years ago

Component: undeterminedffmpeg

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.

comment:3 by Linjie.Fu, 6 years ago

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

comment:4 by U. Artie Eoff, 6 years ago

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

Is that patch ready to be merged yet?

Note: See TracTickets for help on using tickets.