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 792773 - vp8parser: it should use the whole frame size, not the first partition size, to initialize the bool decoder
vp8parser: it should use the whole frame size, not the first partition size, ...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-01-22 09:43 UTC by zj,wang
Modified: 2018-01-30 19:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
source file (1.52 KB, video/webm)
2018-01-23 01:32 UTC, zj,wang
  Details
more gpuhang streamers (882 bytes, video/webm)
2018-01-24 04:12 UTC, zj,wang
  Details
two more files (882 bytes, video/webm)
2018-01-24 04:12 UTC, zj,wang
  Details
Fix bool decoder init (1.35 KB, patch)
2018-01-25 04:58 UTC, sreerenj
committed Details | Review

Description zj,wang 2018-01-22 09:43:27 UTC
Test Env:
============================================
Platform:               SKL/APL/KBL
Arch:          		x86_64
Kernel:			4.12.0-rc2
libva	94fdf9cb759e3bc29ac952fb63a9cd8348173728 
repo: https://github.com/01org/libva.git

libva-intel	3d5c53dcdc25ea09c6a469c91c2555ad63e2b7a0  
repo: https://github.com/01org/intel-vaapi-driver.git

libva-utils	7b4827ed5e9ed7aef438c321e8d2a27e9ab56a28 
repo: https://github.com/01org/libva-utils.git

gst-vaapi	ce3593c0f6999b6ceb77c16360e61973e2a59945 
repo:  git://anongit.freedesktop.org/gstreamer/gstreamer-vaapi


Reproduce Steps:
============================================
1. build env as above
2. gst-launch-1.0 -f -q filesrc location=/media/vp8_vpg/vp8_rev0_P_frame_ZeroMV.webm '!' matroskademux '!' vaapivp8dec '!' vaapipostproc format=i420 '!' checksumsink2 frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE
3. run "dmesg |grep hang", find that gpu hang occurs.
Comment 1 Víctor Manuel Jáquez Leal 2018-01-22 11:42:45 UTC
@zj.wang can you attach the media file vp8_rev0_P_frame_ZeroMV.webm? 
Or can you send it to me by email?
Comment 2 zj,wang 2018-01-23 01:32:07 UTC
Created attachment 367269 [details]
source file

upload the decoding source file
Comment 3 zj,wang 2018-01-24 04:12:15 UTC
Created attachment 367353 [details]
more gpuhang streamers
Comment 4 zj,wang 2018-01-24 04:12:42 UTC
Created attachment 367354 [details]
two more files
Comment 5 zj,wang 2018-01-24 04:13:06 UTC
upload two more source files which also occur gpu hang during doing vp8 decoding

vp8_rev0_InterFrame_NewMV_Anim.webm 
vp8_rev0_I_frame_H_Anim.webm
Comment 6 sreerenj 2018-01-24 18:09:42 UTC
@zj, is it a regression in recent version of gstreamer-vaapi+intel-vapai-driver?

Can you test it with bit older versions (libva-1.x and gstreaemr-1.12.0 for eg) ?
Is it working with other middleware software like libyami?
Also, Can you please test only the decode scenario: vaapivp8dec ! fakesink
Comment 7 Víctor Manuel Jáquez Leal 2018-01-24 19:23:51 UTC
(In reply to sreerenj from comment #6)


I have just tested with libva 1.8 with the intel-vaapi-driver, same version, and the GPU hang is there.

> Also, Can you please test only the decode scenario: vaapivp8dec ! fakesink

Precisely I did that, and there's NO GPU hang.

It seems that the hang is when the sufrace is rendered, either as a image (for software processing) or as a display's surface (vaapisink).

> Is it working with other middleware software like libyami?

In the github issue, it is mentioned that they did it with libyami, without a gpu hang, but now I wonder if they did the rendering of the surface.
Comment 8 sreerenj 2018-01-24 23:25:14 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #7)
> (In reply to sreerenj from comment #6)
> 
> 
> I have just tested with libva 1.8 with the intel-vaapi-driver, same version,
> and the GPU hang is there.
> 
> > Also, Can you please test only the decode scenario: vaapivp8dec ! fakesink
> 
> Precisely I did that, and there's NO GPU hang.

Strange!I can reproduce this issue in KBL just with decoding :)
How did you check the gpu hang? you have to run dmesg couple of times, first run might not show the debug message.

> 
> It seems that the hang is when the sufrace is rendered, either as a image
> (for software processing) or as a display's surface (vaapisink).
> 
> > Is it working with other middleware software like libyami?
> 
> In the github issue, it is mentioned that they did it with libyami, without
> a gpu hang, but now I wonder if they did the rendering of the surface.


I tried with yami,but can't even run the decode !

If I disable the non-zero-coefficient skipping then there is no gpu hang. But it is wrong to hardcode the value. Let me confirm with some vp8 experts.
Comment 9 haihao.xiang 2018-01-25 00:37:34 UTC
Some parameters from gstreamer-vaapi are wrong, please check macroblock_offset and partition_size[0]

[61589.037137][ctx 0x02000000]  --VASliceParameterBufferVP8
[61589.037138][ctx 0x02000000]  slice_data_size = 879
[61589.037138][ctx 0x02000000]  slice_data_offset = 10
[61589.037138][ctx 0x02000000]  slice_data_flag = 0
[61589.037139][ctx 0x02000000]  macroblock_offset = -1073740613
[61589.037139][ctx 0x02000000]  num_of_partitions = 2
[61589.037139][ctx 0x02000000]  partition_size[0] = -402653181
[61589.037140][ctx 0x02000000]  partition_size[1] = 714
[61589.037140][ctx 0x02000000]  partition_size[2] = 0
[61589.037140][ctx 0x02000000]  partition_size[3] = 0
Comment 10 sreerenj 2018-01-25 00:44:37 UTC
(In reply to haihao.xiang from comment #9)
> Some parameters from gstreamer-vaapi are wrong, please check
> macroblock_offset and partition_size[0]
> 
> [61589.037137][ctx 0x02000000]  --VASliceParameterBufferVP8
> [61589.037138][ctx 0x02000000]  slice_data_size = 879
> [61589.037138][ctx 0x02000000]  slice_data_offset = 10
> [61589.037138][ctx 0x02000000]  slice_data_flag = 0
> [61589.037139][ctx 0x02000000]  macroblock_offset = -1073740613
> [61589.037139][ctx 0x02000000]  num_of_partitions = 2
> [61589.037139][ctx 0x02000000]  partition_size[0] = -402653181
> [61589.037140][ctx 0x02000000]  partition_size[1] = 714
> [61589.037140][ctx 0x02000000]  partition_size[2] = 0
> [61589.037140][ctx 0x02000000]  partition_size[3] = 0

Just found it and about to comment :), thanks Haihao.

The boolean decoder in gstreamer codec parser is messing up something.
Comment 11 sreerenj 2018-01-25 04:34:28 UTC
This issue is caused by the confusion between vp8 spec and what libvpx implemented. Let's follow what libvpx is doing and that will fix the issue.

According to the vp8 spec, the first partition (size can be derived from the frame header) should have all compressed header information and if that is true, gst codecparser should work fine because we initialize the range decoder with the exact size that derived from frame header, rather than using the actual buffer size (total frame size). 

But it doesn't seem to be the case with some of the streams (all the attached streams) and libvpx works fine because it uses the whole frame size (not the first partition size) to initialize the bool decoder.
Comment 12 sreerenj 2018-01-25 04:58:21 UTC
Created attachment 367409 [details] [review]
Fix bool decoder init
Comment 13 sreerenj 2018-01-25 04:59:36 UTC
@zj: Could you please have a try with the attached patch (apply the patch on top of gst-plugins-bad)?
Comment 14 zj,wang 2018-01-25 06:09:41 UTC
Hi Sree

after pull the latest commit of gst-bad a1b271d2ecd9dfc60c12e90abcbbe9c18c8eed4f, it reminds me error "undefined reference" during compiling. Besides, I have applied the latest gstreamer/gst-base/gst-good/gst-ugly. So which commit of every component do you use and can you provide them to me?

.libs/gst-plugins-bad-libs-scan.o: In function `get_object_types':
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:32: undefined reference to `gst_mpegts_section_type_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:33: undefined reference to `gst_mpegts_section_table_id_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:35: undefined reference to `gst_mpegts_cable_outer_fec_scheme_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:36: undefined reference to `gst_mpegts_modulation_type_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:37: undefined reference to `gst_mpegts_satellite_polarization_type_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:38: undefined reference to `gst_mpegts_satellite_rolloff_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:39: undefined reference to `gst_mpegts_dvb_code_rate_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:40: undefined reference to `gst_mpegts_descriptor_type_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:41: undefined reference to `gst_mpegts_iso639_audio_type_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:42: undefined reference to `gst_mpegts_running_status_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:43: undefined reference to `gst_mpegts_dvb_service_type_get_type'
/root/build/gst-plugins-bad/docs/libs/gst-plugins-bad-libs-scan.c:44: undefined reference to `gst_mpegts_stream_type_get_type'
Comment 15 Víctor Manuel Jáquez Leal 2018-01-25 12:42:07 UTC
attachment 367353 [details] and attachment 367354 [details] are the same
Comment 16 Víctor Manuel Jáquez Leal 2018-01-25 12:53:29 UTC
(In reply to sreerenj from comment #13)
> @zj: Could you please have a try with the attached patch (apply the patch on
> top of gst-plugins-bad)?

I just tried it and both streams play without gpu hanging. I tried another three vp8 streams and also did work.

So the issue belongs to the parser rather than the vaapidecoder itself. Let me reassign the bug's component.
Comment 17 sreerenj 2018-01-25 17:48:23 UTC
@Victor: Thanks for testing. I will push it if no one has objections.

@zj: Try with a clean version of gst* including gst-plugins-bad.
Comment 18 sreerenj 2018-01-30 19:35:52 UTC
Review of attachment 367409 [details] [review]:

Pushed as cedc7d4def9860d3fba2884a7a44f827e9903f68