Comment # 11 on bug 1095014 from Vasilis Liaskovitis

(In reply to Stefan Dirsch from comment #10)
> (In reply to Stefan Dirsch from comment #9)
> > Could be that this is no longer an issue and meanwhile has been resolved
> > thru other means ...
>
> Not really.
> Both commands are crashing with a Segfault on Wayland and work fine on X11.
>
>   mpv --hwcodec=vaapi --vo=vaapi <file>
>   mpv --hwcodec=vdpau --vo=vdpau <file>

is there a core dump?

>
> whereas
>
>   mpv --hwcodec=no <file>
>
> works on both sessions. Need to have a closer look later ...

The following guide suggests --vo=gpu should be used (along with --hwdec=vaapi
if e.g. vaapi decoding is needed). Using --vo=vaapi should be avoided.
https://github.com/mpv-player/mpv/wiki/Which-VO-should-I-use%3F

I assume the latest tests are still on sle15, correct?

I don't have a physical sle15 machine at the moment, but TW with amdgpu works
on wayland as well with the following:

mpv --vo=gpu --hwdec=vaapi --gpu-context=wayland /mnt/test.mp4
Playing: /mnt/test.mp4
 (+) Video --vid=1 (*) (h264 1280x720 25.000fps)
 (+) Audio --aid=1 (*) (aac 6ch 48000Hz)
[ffmpeg] AVHWFramesContext: Failed to create surface: 2 (resource allocation
failed).
[ffmpeg] AVHWFramesContext: Unable to allocate a surface from internal buffer
pool.
AO: [pulse] 48000Hz 5.1 6ch float
Using hardware decoding (vaapi).
VO: [gpu] 1280x720 vaapi[nv12]
AV: 00:00:03 / 00:02:50 (2%) A-V:  0.000

Despite the "unable to allocate" message, I think CPU usage is 5-6% and libva
is used.

Whereas without "--hwdec=vaapi" i.e. command "mpv --vo=gpu
--gpu-context=wayland /mnt/test.mp4" CPU usage is 15-20%.

On xorg use:

mpv --vo=gpu --hwdec=vaapi --gpu-context=x11egl /mnt/test.mp4

mpv versions on TW and sle15 are both mpv-0.29.1, though not exactly the same.
Are you using 0.29.1 ?

If the problem still persists with the above command line: I am not sure what
has changed between sle15 and TW. Maybe something in mpv or XWayland fixes
between SLE15 xorg-x11-server-1.19.6 and TW xorg-x11-server-1.20.7 ?


Anyway you are right of course that the libva/intel-vaapid-river DRI3  patches
are still blocked upstream.