output yuv green screen when decode h264 file using sample decode

[lzfgnu]

here is input h264 file h264.zip

platform: windows10 1909 cpu: Intel Core i7-8700 gpu: intel uhd graphics 630 ram: 16gb

[wangyan-intel]

What platform?

[lzfgnu]

What platform?

platform: windows10 1909 cpu: Intel Core i7-8700 gpu: intel uhd graphics 630 ram: 16gb

Here is my computer config. I also tested in my laptop thinkpad t480, the same problem appeared

Thinkpad t480's config: platform: window10 1909 cpu: Intel Core i5-8250U gpu: intel uhd graphics 620 ram: 16gb

[wangyan-intel]

@chuanli1 could you please check it? Thanks.

[chuanli1]

sure

[dmitryermilov]

@lzfgnu , please post: 1) Driver version 2) command line you used? 3) info if the issue is seen or not with YUV file dumping

Thanks.

[lzfgnu]

@lzfgnu , please post:

1. Driver version
2. command line you used?
3. info if the issue is seen or not with YUV file dumping

Thanks.

Thanks for your reply. Here is my computer information

1. Driver version: Intel UHD Graphics 630 (26.20.100.7642)
2. Command line: sample_decode h264 -i input.h264 -o output.yuv
3. The issue is seen with yuv file. some frames are normal while some frames are green.

[dmitryermilov]

Thanks. Could you try to add "-hw -d3d" or "-hw -d3d11" cmd option? Will you see the same green frames?

[lzfgnu]

Thanks. Could you try to add "-hw -d3d" or "-hw -d3d11" cmd option? Will you see the same green frames?

I tried but the issue is still existed

[chuanli1]

• windows

sample_decode.exe h264 -i data.h264 -o output_d3d.yuv -hw -d3d the result: [ERROR], sts=MFX_ERR_NULL_PTR(-2), CDecodingPipeline::CreateHWDevice, m_hwdev->Init failed at d:\bb\nnt-bldsrv-03_2\build_windows_sw_lib\build_dir\repos\mdp_msdk-lib\samples\sample_decode\src\pipeline_decode.cpp:1060

[ERROR], sts=MFX_ERR_NULL_PTR(-2), CDecodingPipeline::Init, CreateHWDevice failed at d:\bb\nnt-bldsrv-03_2\build_windows_sw_lib\build_dir\repos\mdp_msdk-lib\samples\sample_decode\src\pipeline_decode.cpp:436

[ERROR], sts=MFX_ERR_NULL_PTR(-2), wmain, Pipeline.Init failed at d:\bb\nnt-bldsrv-03_2\build_windows_sw_lib\build_dir\repos\mdp_msdk-lib\samples\sample_decode\src\sample_decode.cpp:730

sample_decode.exe h264 -i data.h264 -o output_d3d11.yuv -hw -d3d11 and sample_decode.exe h264 -i data.h264 -o output_d3d11.yuv -hw the result: A green screen appears in the fifth frame,and subsequent frames can occasionally be decoded.

• linux

./sample_decode h264 -i /home/gta/data.h264 -o output_linux.yuv -hw the result: can decode successfully

[chuanli1]

Some frames have no valid reference frame to decode,so some green screens appear. I need to check why the app don‘t send this reference frame to lib.

[chuanli1]

1.The m_index value change of the first frame is 1,no reference frame, because this is a IDR frame; (successfully) the m_index of current frame: 1 2.The m_index value change of the second frame is 1,-1,0 (successfully) the m_index of current frame: 0 the m_index of marked reference frame : 1 3.The m_index value change of the third frame is 1,-1,0,-1,3 (successfully) the m_index of current frame: 3 the m_index of marked reference frame : 0 4.The m_index value change of the fourth frame is 1,-1,0,-1,3,-1,2 (successfully) the m_index of current frame: 2 the m_index of marked reference frame : 3 5.The m_index value change of the fifth frame is 1,-1,0,-1,3,-1,2,-1,5 (failed) the m_index of current frame: -1 the m_index of marked reference frame : 5 So the fifth frame reference mark error.

[chuanli1]

[root cause]: From the fourth frame to the fifth frame, the value of frame_num changes directly from 3 to 5, for frame_num is a discontinuous value, lib code fills the frame_num gap with non-existing frames. When processing the non-existent frames, the fourth frame that has been previously marked as a reference frame is removed again, and the non-existent frame is marked as a reference frame.

[dmitryermilov]

@chuanli1 , thanks for root cause description. Need some conclusion. Could you say if it's a bug or the stream is corrupted or something else?

• If it's a bug, please provide reference to AVC spec wording which confirms it. Please also provide some ETA.
• If it's a corrupted stream, please tell if decoder can potentially handle it. Decoder should be error tolerant.
• If it's a corrupted stream, and decoder can't even theoretically handle it, please explain why.

[chuanli1]

thanks @dmitryermilov .

1. bug: When processing discontinuous frame_num, ProcessFrameNumGap function modify the marked reference frame in DBP.
2. solution: When processing discontinuous frame_num, first step judge whether there have the mark reference frames according to count NumShortTermRefs and NumLongTermRefs. If not, the lib continue to fill the frame_num gap with non-existing frames to ensure that this kind of cases can pass, if yes, the lib don‘t need to execute the first step and continue to use the already marked reference frame.
3. patch: I will submit a patch today.

[chuanli1]

Hi @lzfgnu, the latest version have fixed this issue, could you check it?

[wangyan-intel]

@lzfgnu We find this issue has been fixed in the latest version. If you still has this issue, you could reopen it. Thanks.