GNOME Bugzilla – Bug 792773
vp8parser: it should use the whole frame size, not the first partition size, to initialize the bool decoder
Last modified: 2018-01-30 19:37:02 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.
@zj.wang can you attach the media file vp8_rev0_P_frame_ZeroMV.webm? Or can you send it to me by email?
Created attachment 367269 [details] source file upload the decoding source file
Created attachment 367353 [details] more gpuhang streamers
Created attachment 367354 [details] two more files
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
@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
(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.
(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.
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
(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.
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.
Created attachment 367409 [details] [review] Fix bool decoder init
@zj: Could you please have a try with the attached patch (apply the patch on top of gst-plugins-bad)?
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'
attachment 367353 [details] and attachment 367354 [details] are the same
(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.
@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.
Review of attachment 367409 [details] [review]: Pushed as cedc7d4def9860d3fba2884a7a44f827e9903f68