avcodec/vaapi_av1: correct data size when create slice data buffer

[feiwan1]

Set all tiles size to create slice data buffer, hardware will use
slice_data_offset/slice_data_size in slice parameter buffer to get
each tile's data.

This change will let it success to decode clip which has multi
tiles data inside one OBU.

Signed-off-by: Fei Wang fei.w.wang@intel.com

[xhaihao]

LGTM

[a1rwulf]

Please have a look at my comment in intel/media-driver#1155
While this is definitely an improvement, I don't think it's fully solved yet.

[feiwan1]

Please have a look at my comment in intel/media-driver#1155
While this is definitely an improvement, I don't think it's fully solved yet.

Thanks @a1rwulf to report this. I will take a look at this. Will update this PR recently.

[a1rwulf]

@feiwan1 sorry for the noise, the issues I still had were caused by me creating 8 instead of 16 surfaces in vaCreateSurfaces.
I can verify that your patch works fine for my 8bit samples in kodi and mpv.
Others also confirmed mpv working on their end.
Well done, thanks for the fast fix.
I have a 10bit sample that shows some artifacts in mpv and crashes in kodi, but that's unrelated and needs more investigation.

Will you submit your patch to the ffmpeg ML?

[feiwan1]

8 inste

Hi @a1rwulf , I have submit the patch to ffmpeg community:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210517015036.22156-1-fei.w.wang@intel.com/

If possible, please comment +1 if you received the ML, which will promote the patch merged.

For your 10bit case, you can use ffmpeg cmdline to check quickly, decode the clip to P010 yuv file, and check if the yuv file can be played by yuv player, if not, please share your clips to me. Thanks.
cmdline:
$ ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v debug -c:v av1 -i input_10bit.ivf -pix_fmt yuv420p10le -vsync passthrough -y out_10bit.yuv

[a1rwulf]

Hi @feiwan1 ,
I posted a +1 on ffmpeg's ML for your patch.
As for the 10bit sample, decoding the clip using your command into a yuv file and then playing it with ffplay, it doesn't look correct.
I used this sample: http://download.opencontent.netflix.com.s3.amazonaws.com/AV1/Chimera/Old/Chimera-AV1-10bit-1920x1080-6191kbps.mp4

Hope this helps.

[uartie]

@feiwan1 is this patch resolved? If so, please close.

[feiwan1]

@feiwan1 is this patch resolved? If so, please close.

The 8bit issue is resolved, close this PR since this pr already merged into upstream. And also can avoid take resource of our CI test.

Will keep taking here with @a1rwulf about 10bit issue. Thanks.

[feiwan1]

Hi @a1rwulf , for your clip, I checked the first 300 frames yuv and seem the incorrect issue is some random noise appear in the end frames of an GOP. Obviously in frame about 100~110 with background. It's like:

Just want to confirm if you met the same issue with me? Thanks.

[a1rwulf]

@feiwan1 yes, that's exactly how the intro looks like when I use mpv for playback.

[feiwan1]

@feiwan1 yes, that's exactly how the intro looks like when I use mpv for playback.

Ok, it seems caused by film grain, I will check it.

[a1rwulf]

@feiwan1 glad you already have an idea of where stuff goes wrong.
Just ping me when there's something to verify.

[feiwan1]

Hi @a1rwulf , I developed PR #412 which can fix your 10bit issue, and improved decode quality for some other clips. You can have a try. I will submit it into community after my test and without regression. Thanks!

[a1rwulf]

Thanks @feiwan1, I've built your #412 PR and the mentioned sample above can be played without artifacts now in mpv.
I don't have a lot of testclips but also the 8bit sample is still fine.