sample decode lost frames

[mamingy2]

System information

• 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
• VGA compatible controller [0300]: Intel Corporation Device [8086:9a49] (rev 01)

Issue behavior

Command

sample_decode h265 -i xxx.h265 -o xxx.yuv

Describe the current behavior

There are 50 frames in the HEVC stream, but the output file only has 34 frames. libva info: VA-API version 1.17.0 libva info: User environment variable requested driver 'iHD' libva info: Trying to open /home/mmy0/media//lib/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_15 libva info: va_openDriver() returns 0 Decoding Sample Version 8.4.27.0

Input video HEVC Output format NV12

Frame rate 25.00 Memory type system MediaSDK impl hw MediaSDK version 1.35

Decoding started Frame number: 34, fps: 21.975, fread_fps: 0.000, fwrite_fps: 42.694 Decoding finished

[brmarkus]

You might get asked by engineering team to provide the video-file you can reproduce the behavior for further analysis. Is the stream originally a (wireless)network stream and might be corrupted? Have you looked into the stream with a stream-analyzer, to check the references between the frames? Can you provide details about the stream itself (like bitrate, GOP-structure, is it I-frames only, with or without B frames)? Do you see the same reduced number of frames with e.g. ffmpeg or gstreamer using the same stream?

Which operating-system do you use? How have you installed MediaSDK, libva and media-driver? Pre-installed, built from source-code?

Would you mind adding additional log-messages to "sample_decode"? In the method CDecodingPipeline::RunDecoding() you might want to check the Corrupted flag pOutSurface->Data.Corrupted after decoding and print the bitmask.

MFX_CORRUPTION_MINOR | Minor corruption in decoding certain macro-blocks -- | -- MFX_CORRUPTION_MAJOR | Major corruption in decoding the frame MFX_CORRUPTION_REFERENCE_FRAME | Decoding used a corrupted reference frame. MFX_CORRUPTION_REFERENCE_LIST | The reference list information of this frame does not match what is specified in the Reference PictureMarking Repetition SEI message. MFX_CORRUPTION_ABSENT_TOP_FIELD | Top field of frame is absent in bitstream. Only bottom field has been decoded. MFX_CORRUPTION_ABSENT_BOTTOM_FIELD | Bottom field of frame is absent in bitstream. Only top filed has been decoded.

[mamingy2]

You might get asked by engineering team to provide the video-file you can reproduce the behavior for further analysis. Is the stream originally a (wireless)network stream and might be corrupted? Have you looked into the stream with a stream-analyzer, to check the references between the frames? Can you provide details about the stream itself (like bitrate, GOP-structure, is it I-frames only, with or without B frames)? Do you see the same reduced number of frames with e.g. ffmpeg or gstreamer using the same stream?

Which operating-system do you use? How have you installed MediaSDK, libva and media-driver? Pre-installed, built from source-code?

Would you mind adding additional log-messages to "sample_decode"? In the method CDecodingPipeline::RunDecoding() you might want to check the Corrupted flag pOutSurface->Data.Corrupted after decoding and print the bitmask.

MFX_CORRUPTION_MINOR Minor corruption in decoding certain macro-blocks MFX_CORRUPTION_MAJOR Major corruption in decoding the frame MFX_CORRUPTION_REFERENCE_FRAME Decoding used a corrupted reference frame. MFX_CORRUPTION_REFERENCE_LIST The reference list information of this frame does not match what is specified in the Reference PictureMarking Repetition SEI message. MFX_CORRUPTION_ABSENT_TOP_FIELD Top field of frame is absent in bitstream. Only bottom field has been decoded. MFX_CORRUPTION_ABSENT_BOTTOM_FIELD Bottom field of frame is absent in bitstream. Only top filed has been decoded.

The file can be opened by VQA. FFmpeg-qsv and gst-msdk shows the same results. But other decoder like vaapi or openhevc in Gstreamer can decode all frames. Built from source and the corrupted is always 0 in decoded frames.

Anyway, can I send the file to your email recoded in your github homepage?

[brmarkus]

Thank you for sharing the video-file. However, I cannot see anything suspicious with it. I tested it on another system (ADL), using sample_decode from OneVPL/OneAPI as well as with MediaSDK under Ubuntu 22.04. According to sample_decode console output, yes, I can see 34 frames being processed. Yes, with ffprobe and VQA/VCA I can see 50 frames encoded.

Let's see if someone from the engineering-team can have a look as well.

Could you share the file here in Github as well for the community, or is it a project-/customer-specific file?

[mamingy2]

Thank you for sharing the video-file. However, I cannot see anything suspicious with it. I tested it on another system (ADL), using sample_decode from OneVPL/OneAPI as well as with MediaSDK under Ubuntu 22.04. According to sample_decode console output, yes, I can see 34 frames being processed. Yes, with ffprobe and VQA/VCA I can see 50 frames encoded.

Let's see if someone from the engineering-team can have a look as well.

Could you share the file here in Github as well for the community, or is it a project-/customer-specific file?

Great thanks!

The file is not good to share in Github, but you can share it inside Intel. BTW, should I open another issue in VPL page? Actually, I use the MediaSDK. If there will be a more rapid response, I can do it.

[brmarkus]

Yes, could be helpful to address to the OneVPL as well - as I was able to reproduce with oneVPL on a machine as well. Analysis and explanations of the seen behavior will be helpful; potentially a bugfix or workaround for MediaSDK and OneVPL would be a different topic.

[mamingy2]

Closed for open another issue in oneVPL page.