On 2018-02-16 01:31 PM, Mark Thompson wrote:
On 16/02/18 17:53, James Zhu wrote:
Hi Mark,
I couldn't reproduce the issue on my Polaris 11 to run mpv / ffmpeg about 1.5
hours.
one terminal run:
ffmpeg -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i video/Mr.Right.mp4 -an -c:v hevc_vaapi -bf 0
out.mp4
the other terminal run:
mpv --fs --loop --no-audio --vo gpu --gpu-context=x11egl --hwdec=vaapi
video/Mr.Right.mp4
But it has some failure with vaDeriveImage. I am not sure if this failure
matters, the video still can play without any other error,
If it's calling vaDeriveImage() at all that suggests it isn't using the proper
interop path, and may be falling back to software decode. This should work in
recent versions of mpv with git Mesa and libva - maybe have a look at the
verbose output and see what it's actually doing?
I think you are right, it should fall back to software decode. During
the weekend test, my system hung also with legacy VAAPI test output setting.
mpv --fs --loop --no-audio --vo vaapi --hwdec=vaapi video/Mr.Right.mp4
No error reported with this command line.
I haven't tried the legacy VAAPI test output, I'll try later to see if that
also triggers the failure for me.
I don't think that this sort of issue should block the patches in Mesa because
it looks likely that it is a kernel issue somehow - userspace shouldn't be able
to nuke the GPU at all. Still, the feature is essentially unusable for me
because of this problem, and I imagine it will apply to at least some other
people with setups which are match mine in some way as yet unknown.
Yeah, if there are no more comments from the community. We will push the
patches to the upstream tomorrow.
Thanks,
- Mark
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
