[Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode
James Zhu
jamesz at amd.com
Mon Feb 19 12:00:05 UTC 2018
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
More information about the mesa-dev
mailing list