[FFmpeg-vaapi][vp9 10bit][decode]

[fulinjie]

Tested on ICL with b88f49f , and it occurs in KBL, too.

CMD:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose -i vp9_sf_10bit_CrowdRun_256x256_112x112_256x256.ivf -pix_fmt p010le -f rawvideo -y dump.yuv

Error Message:
[MOS]: CRITICAL - Mos_Specific_GetResourceInfo:2169: Invalid (nullptr) Pointer.
[CODEC]:CRITICAL - CodecHalGetResourceInfo:507: MOS returned error, eStatus = 0x5
[CODEC]:CRITICAL - InitPicStateMhwParams:1390: MOS returned error, eStatus = 0x5
[CODEC]:CRITICAL - DecodeStateLevel:533: MOS returned error, eStatus = 0x5
[CODEC]:CRITICAL - Execute:1264: State level decoding failed.
[LIBVA]:CRITICAL - EndPicture:719: DDI:DdiDecode_DecodeInCodecHal return failure.
[vp9 @ 0x2288380] Failed to end picture decode issue: 23 (internal decoding error).
[MOS]: CRITICAL - Mos_Specific_GetResourceInfo:2169: Invalid (nullptr) Pointer.
[CODEC]:CRITICAL - CodecHalGetResourceInfo:507: MOS returned error, eStatus = 0x5
[CODEC]:CRITICAL - InitPicStateMhwParams:1390: MOS returned error, eStatus = 0x5
[CODEC]:CRITICAL - DecodeStateLevel:533: MOS returned error, eStatus = 0x5
[CODEC]:CRITICAL - Execute:1264: State level decoding failed.
[LIBVA]:CRITICAL - EndPicture:719: DDI:DdiDecode_DecodeInCodecHal return failure.
[vp9 @ 0x2290780] Failed to end picture decode issue: 23 (internal decoding error).

Analysis:
In DdiDecodeVP9::ParsePicParams,
picParam->reference_frames[i] is passed correctly from FFmpeg level, but GetRenderTargetID falled to get the frameIdx.

media-driver/media_driver/linux/common/codec/ddi/media_ddi_decode_vp9.cpp

Line 127 in f39c5dc

frameIdx = GetRenderTargetID(&m_ddiDecodeCtx->RTtbl, refSurface);

The absence of reference id is the root cause of the failure in CodecHalGetResourceInfo.

[wangyan-intel]

@fulinjie Could you please share your vp9_sf_10bit_CrowdRun_256x256_112x112_256x256.ivf? Thanks.

[wangyan-intel]

@fulinjie I just submitted one patch to FFMPEG maillist. This issue comes from FFMPEG destroy VAAPI context when the resolution of the 2nd frame is different with the 1st frame. It will cause reference frame surface lost. Thanks.
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244711.html

[fulinjie]

Update:

VP9 allows resolution changes per frame. Currently in VAAPI, resolution
changes leads to va context destroy and reinit. This will cause
reference frame surface lost and produce garbage.

Though refs surface id could be passed to media driver and found in
RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus the
new created VaContext could only got an empty RefList.

As libva allows re-create surface separately without changing the
context, this issue could be handled by only recreating hw_frames_ctx.

https://patchwork.ffmpeg.org/patch/13895/

There is still possibility for reconstruct vp9RefList[].

Destroy/recreate context is a common pipeline for all hardware codec, specific code is hacky in general path.
As FFmpeg has the ability to pass the refs surface id to driver, I think maintainers would prefer have this fixed internally in driver.

[XinfengZhang]

middle ware issue, should not traced here

[XinfengZhang]

it is different, media driver will keep some inter-media variables for different frames, different codec should have different inter-media variable required. for example: for h264, MV of P frame should be kept for future B frame. application should not destroy/re-create the context.