Page MenuHomeSolus

Intel VA-API (hardware video decode) fails using both mpv and vlc
Closed, ResolvedPublic

Description

I have a pretty low end machine (AcerC720) and I relied on hardware accelerated video decode for smooth video playback using Arch which worked flawlessly. This is currently a blocker for me switching to solus.

Prerequisites
an intel gpu
intel vaapi driver

# eopkg it libva-intel-driver

mpv and vlc

# eopkg it mpv vlc

Testing
Running these commands

$ vainfo
$ mpv --profile=opengl-hq --hwdec=vaapi test.file
$ vlc --vout=glx --avcodec-hw=vaapi test.file

This is the test file I used: https://www.dropbox.com/s/zr068zb69lvs9ht/1080i_4ChAud.ts

Output from Arch


Output from Solus

Under solus both mpv and vlc fall back to software decoding even though the output from vainfo suggests that vaapi is correctly configured on the system.

The most helpful output is from mpv which says:
VO does not support requested hardware decoder, or loading it failed.

Further reading
https://wiki.archlinux.org/index.php/Hardware_video_acceleration

Event Timeline

I am able to repro this on my Kaby Lake (i3-7100U) system with Solus 2017.01.01.0. From the output of vainfo, VAAPI appears properly configured on my system. I see no explicit error messages from either VLC or MPV but logs and CPU usage indicate fallback to software rendering. Repros with known good media (Big Buck Bunny H.264/1080p) so it doesn't appear to be media-specific but could still possibly be related to AVC profile / level detection. Will continue to investigate.

At least it's not just me!

If you install the the va-gl driver to use vdpau as a frontend for vaapi

# eopkg it libvdpau-va-gl

and vdpauinfo (you have to build it yourself from here https://dev.solus-project.com/T2035)

The output of vdpauinfo reports

$ vdpauinfo
display: :0   screen: 0
[VS] Software VDPAU backend library initialized
...

The last line doesn't seem right, and wasn't there from the output of vdpauinfo under Arch.
Not sure what it means exactly at the moment.

@joebonrichie Debugging mpv it seems like there could be a pixel format mismatch that's causing it to fall back on software decoding. Could you attach the mpv.log produced by this command on your working Arch install?

mpv --profile=opengl-hq --hwdec=vaapi --msg-level=all=v --log-file=mpv.log ~/Downloads/1080i_4ChAud.ts

JoshStrobl triaged this task as Normal priority.Jan 8 2017, 2:56 AM
JoshStrobl removed a project: Triage Team.
JoshStrobl moved this task from Backlog to Improvement on the Software board.

@joebonrichie Actually no need. I figured it out. ffmpeg was being compiled without the --enable-vaapi option so dependent apps didn't think it was available. I have a patch for the ffmpeg package that I've verified fixes this. Thanks for reporting the issue.

I can't believe I didn't check the ffmpeg package, i checked every other relevant package smh

Thanks a lot though, the issue is resolved I compiled ffmpeg with vaapi support and both mpv and vlc were able to use hardware decoding.

Heres the output from mpv now, just for consistency

$ mpv --profile=opengl-hq --hwdec=vaapi ~/Downloads/1080i_4ChAud.ts 
Playing: /home/ninya/Downloads/1080i_4ChAud.ts
...
ffmpeg errors
...
 (+) Video --vid=1 (h264)
 (+) Audio --aid=1 --alang=eng (mp2)
     Audio --aid=2 --alang=spa (mp2)
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
AO: [pulse] 48000Hz stereo 2ch s16
Using hardware decoding (vaapi).
VO: [opengl] 1920x1080 vaapi
AV: 00:00:33 / 00:00:48 (71%) A-V:  0.000
$ ps aux | grep mpv
ninya    13214 12.2  3.6 1189240 67348 pts/1   Sl+  12:16   0:02 mpv --profile=opengl-hq --hwdec=vaapi /home/ninya/Downloads/1080i_4ChAud.ts
ikey claimed this task.
ikey added a subscriber: ikey.

Confirmed as working here with the latest updates and libva-intel-driver. Thanks!

 ✓  ikey@solus-bdw  ~/Downloads  vlc http://download.blender.org/peach/trailer/trailer_1080p.ogg
VLC media player 2.2.4 Weatherwax (revision 2.2.3-37-g888b7e89)
[0000000000da4078] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[VS] Software VDPAU backend library initialized
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
[00007fb26c001268] vdpau_display vout display error: source video chroma type not supported
QObject::~QObject: Timers cannot be stopped from another thread

I have an i3-7100U too and have VAAPI working with "mpv --hwdec=vaapi" (--profile=opengl-hq was too slow). Even though it should work, mpv does not show any error, it uses a lot of CPU. I have tested H.264 10-bit and H.265 10-bit files which on Windows plays with no CPU usage. Any idea why this happens?

mpv --hwdec=vaapi 20171125.m4v
Playing: 20171125.m4v
 (+) Video --vid=1 (*) (hevc 1920x1080 29.895fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 1ch 48000Hz)
File tags:
 Title: VID_20171125_180204
AO: [pulse] 48000Hz mono 1ch float
VO: [opengl] 1920x1080 yuv420p12
AV: 00:00:00 / 00:00:21 (0%) A-V:  0.333 Dropped: 1

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

AV: 00:00:18 / 00:00:21 (82%) A-V:  0.000 Dropped: 213


Exiting... (Quit)
$ vainfo 
libva info: VA-API version 1.0.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.0 (libva 2.0.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.0.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSliceLP
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointEncSliceLP
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointEncSliceLP
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointEncPicture
      VAProfileVP8Version0_3          :	VAEntrypointVLD
      VAProfileVP8Version0_3          :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointEncSlice
      VAProfileVP9Profile2            :	VAEntrypointVLD

The libva people told me that on Linux H264 10bit is not supported which I now can see when I look closer on the vainfo output. Too bad though considering it's available in Windows.