[regression][ffmpeg-vaapi][vp8d] decode output corrupt

[uartie]

We are observing this issue only on gen 9.5 (KBL/CFL/WHL/CML ...). However, some of our gen9.5 platforms don't exhibit this problem. So maybe it's related to SKU or kernel that causes bad driver behavior?

$ ffmpeg -hwaccel vaapi -init_hw_device vaapi=hw:/dev/dri/renderD128 \
  -hwaccel_flags allow_profile_mismatch -filter_hw_device hw -v verbose \
  -i ./vp8_rev025_CoeffSkip_10_CapitolRecordsNight0.webm \
  -pix_fmt yuv420p -f rawvideo -vsync passthrough -autoscale 0 \
  -vframes 2 -y threads-default.yuv

$ md5sum threads-default.yuv
318bbd5defb50471c1fe5665f2a70c5a  threads-default.yuv

The second frame in threads-default.yuv output is corrupt:

However, if we add -threads 1 to the ffmpeg pipeline, then we get the expected output:

$ ffmpeg -hwaccel vaapi -init_hw_device vaapi=hw:/dev/dri/renderD128 \
  -hwaccel_flags allow_profile_mismatch -filter_hw_device hw -v verbose \
  -threads 1 -i ./vp8_rev025_CoeffSkip_10_CapitolRecordsNight0.webm \
  -pix_fmt yuv420p -f rawvideo -vsync passthrough -autoscale 0 \
  -vframes 2 -y threads-1.yuv

$ md5sum threads-1.yuv
0da047495680366fc428d120368f35e4  threads-1.yuv

We have many other cases that produce this kind of corrupt behavior, too.

[uartie]

This is a regression that started with c383f7e:

commit c383f7ef2d65f523b8b8c70a71c94a296541d5be
Author: XiaogangLi <xiaogang.li@intel.com>
Date:   Fri Jul 17 22:46:42 2020 +0800

    [Media Common] Change SW swizzling to HW copy in lock surface
    
    Use HW copy to improve performance for decode only/encode only and VPP cases.
    
    Change-Id: Ibf7e68c2224598f742e6c869204cf0f95dd3e852

cc: @Xiaogangli-intel

[Xiaogangli-intel]

@uartie This change only impacts the platform which uses SW swizzling(should be >Gen11). So I don't think this issue caused by this change because gen 9.5 (KBL/CFL/WHL/CML ...) are not using SW swizzling.

[uartie]

@uartie This change only impacts the platform which uses SW swizzling(should be >Gen11). So I don't think this issue caused by this change because gen 9.5 (KBL/CFL/WHL/CML ...) are not using SW swizzling.

I checked on several different KBL, CFL and WHL packages SKUs. Some SKUs did not reproduce... but the others reproduce reliably. I also double-checked before and after patch... and regression always after patch.

[uartie]

For example, a i7-7700 (KBL) I tested has 100% reproduced regression. But it is fine before the patch.

[uartie]

Interestingly, on my local KBL Fedora OS development machine, it does not regress before or after this commit. But, if I compile and test in an Ubuntu Bionic Docker container on the same machine, I see the regression after this commit, but not before. Hope this gives some clues.

[uartie]

Interestingly, on my local KBL Fedora OS development machine, it does not regress before or after this commit. But, if I compile and test in an Ubuntu Bionic Docker container on the same machine, I see the regression after this commit, but not before. Hope this gives some clues.

Another observation... with Debug build, the issue goes away in container, too.

[uartie]

@uartie This change only impacts the platform which uses SW swizzling(should be >Gen11). So I don't think this issue caused by this change because gen 9.5 (KBL/CFL/WHL/CML ...) are not using SW swizzling.

But this change does modify some of the code paths taken by gen9.5, right? Perhaps the change exposed a previously dormant multi-thread race condition? Or maybe introduced one by accident?

[uartie]

@Xiaogang-Li @feiwan1 any update?

[Xiaogangli-intel]

@uartie, could you try this patch #1048?

[uartie]

@uartie, could you try this patch #1048?

@Xiaogang-Li yes #1048 appears to resolve this issue. Thanks!

[dvrogozh]

@uartie : is this observation specific to vp8d only or you saw the same on vp9/av1? and did you ever see that on avc/hevc?

[uartie]

@uartie : is this observation specific to vp8d only or you saw the same on vp9/av1? and did you ever see that on avc/hevc?

Only vp8d using ffmpeg-vaapi + iHD as far as I've observed over ~2 months since this regression started.

[uartie]

@uartie : is this observation specific to vp8d only or you saw the same on vp9/av1? and did you ever see that on avc/hevc?

Only vp8d using ffmpeg-vaapi + iHD as far as I've observed over ~2 months since this regression started.

Also, note that adding -threads 1 to ffmpeg-vaapi does not exhibit this issue.