After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793867 - [gstreamer-msdk-master][SKL] 3 cases lose frame during mpeg2 decoding
[gstreamer-msdk-master][SKL] 3 cases lose frame during mpeg2 decoding
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.15.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 793868 (view as bug list)
Depends on: 796477
Blocks: 789886
 
 
Reported: 2018-02-27 03:09 UTC by zj,wang
Modified: 2018-06-11 23:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
decoding stream (328.77 KB, application/octet-stream)
2018-02-27 03:09 UTC, zj,wang
Details
original stream (126.30 KB, application/octet-stream)
2018-06-07 05:44 UTC, zj,wang
Details

Description zj,wang 2018-02-27 03:09:20 UTC
Created attachment 368989 [details]
decoding stream

Test Env:
============================================
Platform:               SKL
Arch:          		x86_64
CentOS Linux release    7.3.1611 (Core)
Kernel:			4.4.0 
libva			MediaServerStudioEssentials2017R3.tar.gz (libva 
                        1.67.0.pre1)
media_driver		MediaServerStudioEssentials2017R3.tar.gz 16.5.2.64009-
                        ubit
gstreamer               master branch 91798e16cc09420163684d13779f13f374164ea2
gst-bad 		master branch 1c81bf4bdc67b518d6b3bbc22398c17fe8ced1da


Reproduce Steps:
============================================
take one case for example
1. build enc as above lists
2. gst-launch-1.0 -q filesrc location=/media/yami_mpeg2/tcela-14-bff-dp.short.bits.mpeg2 '!' mpegvideoparse '!' msdkmpeg2dec '!' videoconvert '!' video/x-raw,format=I420 '!' filesink location=tcela-14-bff-dp.short.bits.mpeg2.yuv
3. dump_file_size=1555200
4. the yuv file size should be 2073600 according to yamidecode.

Failed cases
decode_mpeg2/tcela-14-bff-dp.short.bits.mpeg2 FAIL
decode_mpeg2/tcela-8-fp-dp.bits.mpeg2 FAIL
decode_mpeg2/twilight_zone_mei_MEI2.stream17.mpeg2 FAIL
Comment 1 zj,wang 2018-02-27 03:16:14 UTC
*** Bug 793868 has been marked as a duplicate of this bug. ***
Comment 2 zj,wang 2018-02-27 03:21:06 UTC
decoding stream "tcela-14-bff-dp.short.bits.mpeg2" please view 
https://drive.google.com/drive/folders/19wBvg5NrKhVRGJ_-Ep_vMX5kU-MGANfk
Comment 3 sreerenj 2018-03-30 01:14:52 UTC
Every decoder I have tested (avdec_mpeg2, mpeg2dec, vaapimpeg2dec, and msdkmpegdec) giving different checksums for each frame :)

gst-vaapi (GST_DEBUG=2) and ffmpeg giving some warnings about the damaged file too.

Anyway, let's keep this bug open for now.
Comment 4 zj,wang 2018-05-31 06:48:54 UTC
the 3 cases will decoding fail with commit 0bdcf51baf77926b4f29c01a2fdf133c13aad62e and have the same phenomenon as Bug 793782

env:
libva                   https://github.com/01org/libva.gitb
                        commit 3be72a5a110880f70626d7c3bed953cdde124b2
media_driver		https://github.com/intel/media-driver
                        commit 1c2b0615d749c45c07f9aee6586774816989c5b3
MediaSDK:               https://github.com/Intel-Media-SDK/MediaSDK
                        commit 7c2b069dce7bed268806f680412a2f3b09a52ce9
gst-bad 		master branch 0bdcf51baf77926b4f29c01a2fdf133c13aad62e
Comment 5 sreerenj 2018-05-31 19:25:17 UTC
Actually current git master is working better :)
Now it is outputting 3 frames, and all three have bit exact match with gst-vaapi.
But the fourth frame(last one in the stream) is not pushing downstream, it failed in decode state. I will have a look.
Comment 6 sreerenj 2018-06-01 01:35:40 UTC
The issue is with the codecparser.
gstreamer-vaapi is working fine because it does the internal parsing its own correctly.

This should fix the issue:
https://bugzilla.gnome.org/show_bug.cgi?id=796477
Comment 7 sreerenj 2018-06-01 06:23:53 UTC
(In reply to zj,wang from comment #4)
> the 3 cases will decoding fail with commit
> 0bdcf51baf77926b4f29c01a2fdf133c13aad62e and have the same phenomenon as Bug
> 793782
> 
> env:
> libva                   https://github.com/01org/libva.gitb
>                         commit 3be72a5a110880f70626d7c3bed953cdde124b2
> media_driver		https://github.com/intel/media-driver
>                         commit 1c2b0615d749c45c07f9aee6586774816989c5b3
> MediaSDK:               https://github.com/Intel-Media-SDK/MediaSDK
>                         commit 7c2b069dce7bed268806f680412a2f3b09a52ce9
> gst-bad 		master branch 0bdcf51baf77926b4f29c01a2fdf133c13aad62e

Please try with the git master.
Or make sure you have this patch in place: https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=700d6782cee67d7d9f42bbdad33fbba55cc9ea33
Comment 8 zj,wang 2018-06-07 05:43:21 UTC
aftr apply the latest commit 06f7d1f6c5de7796a656159208b0d8d6d4bf6205
below two cases can be decoded successfully and have no problem
decode_mpeg2/tcela-14-bff-dp.short.bits.mpeg2 
decode_mpeg2/tcela-8-fp-dp.bits.mpeg2

But the third one still has issue. It will lose frame and has garbage in decoded frame. I check the original stream, it has 8 frames and has different resolution from 5th frame.
decode_mpeg2/twilight_zone_mei_MEI2.stream17.mpeg2
Comment 9 zj,wang 2018-06-07 05:44:29 UTC
Created attachment 372587 [details]
original stream
Comment 10 zj,wang 2018-06-07 05:45:24 UTC
I have uploaded the original stream for your information.
Comment 11 zj,wang 2018-06-07 06:46:54 UTC
For case twilight_zone_mei_MEI2.stream17.mpeg2
the size of dumped file by msdk is 2012160, the size of dumped file by vaapi is 2420736, the size of dumped file by libyami is 2420736.

in original stream, it has 4 frames with resolution 704x480 and 4 frames with resolution 256x256, so the dumped file size is 2420736.
in other word, it lose frame by msdk.
Comment 12 sreerenj 2018-06-07 23:54:56 UTC
CheckSum generated with msdkmpeg2dec for NV12 output

FrameChecksum 4c24771c7d6bd81a3dcdb572f3463e46
FrameChecksum cc8c8c8b4df91f7fe01adba888800a84
FrameChecksum 451b3ad37b91bff4dc5e69596a23c94d
FrameChecksum 82313376324735d278544e45d7f90360
FrameChecksum 993e5e9e6e1cda451300c3d1595a7b2e
FrameChecksum c3cc062eb2951b873dffc95bb829d92c
FrameChecksum a38fa7f1fd10383156d7c18a5c8bfe11
FrameChecksum c9f1aeb5a5b56fd8194529edc431e4e9

Checksum generated with vaapi
FrameChecksum 4c24771c7d6bd81a3dcdb572f3463e46
FrameChecksum cc8c8c8b4df91f7fe01adba888800a84
FrameChecksum 451b3ad37b91bff4dc5e69596a23c94d
FrameChecksum a367da2b222919e4abd6192caa017744
FrameChecksum 993e5e9e6e1cda451300c3d1595a7b2e
FrameChecksum c3cc062eb2951b873dffc95bb829d92c
FrameChecksum a38fa7f1fd10383156d7c18a5c8bfe11
FrameChecksum c9f1aeb5a5b56fd8194529edc431e4e9

Only the 4 th frame has a different checksum when decoding with msdk.

I would recommend you to check it with msdk test applications or other msdk based media stacks.

In any case, it is not dropping any frame. So I'm closing this bug. Please open a new one for this sample if msdk test applications work similar to vaapi.
Comment 13 sreerenj 2018-06-11 23:59:29 UTC
The fourth frame md5 mismatch will be handled in https://bugzilla.gnome.org/show_bug.cgi?id=796566