GNOME Bugzilla – Bug 754010
[SKL][Media][decode]AMVP_C_Samsung_4.bin failed when doing HEVC decoding test
Last modified: 2015-11-20 14:39:35 UTC
Created attachment 309903 [details] AMVP_C_Samsung_4 screen shot Following cases failed when doing HEVC decoding test: AMVP_C_Samsung_4.bin DBLK_C_SONY_3.bin DELTAQP_A_BRCM_4.bin DELTAQP_C_SONY_3.bin NUT_A_ericsson_4.bin RAP_B_Bossen_1.bin RPS_C_ericsson_4.bin RPS_D_ericsson_5.bin SAO_B_MediaTek_5.bin SAO_E_Canon_4.bin SAO_F_Canon_3.bin SAO_G_Canon_3.bin SLIST_A_Sony_4.bin SLIST_B_Sony_8.bin SLIST_C_Sony_3.bin SLIST_D_Sony_9.bin TILES_B_Cisco_1.bin 1. Testing Steps: ======================================================================== 1.run command: gst-launch-1.0 filesrc location=/media/HEVC/JVT10.0/AMVP_C_Samsung_4.bin ! vaapiparse_h265 ! "video/x-h265, stream-format=(string)byte-stream" ! vaapidecode ! vaapisink 2.Log: ======================================================================== libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_38 libva info: va_openDriver() returns 0 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'vaapidecode0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL; Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:01.020548769 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... 3. Testing Env: ======================================================================== Libdrm: (master)libdrm-2.4.64-4-g6e84ada4ccf604c32a008fc20c00d79302135601 Mesa: (master)ad89748541159968787dce02bb9c19d9367fddc6 Xserver: (master)xorg-server-1.17.0-297-g7ecdfbf0af3547295b245efa754123db65cabb43 Xf86_video_intel:(master)2.99.917-452-g78f7451886f0a33df717c57fc1a079ee7e6f221e Libva: (master)fdd6ee00c916f530e4d0aa1b250633643999dcf1 Libva_intel_driver:(master)7c47a8f74878904e0d2fbb5da966552f783d74ab Gst_plugins_vaapi10: (master)18a8b87975baf7ad1eb6c02a5dde6889269b33fb Gstreamer: (master)ef3286e0f5e6611f55a2bf5d37244e58d1e29c59 4. Frequency of Occurence: ======================================================================== 100%
Please have a re-run with gst-checksumsink: gst-launch-1.0 filesrc location=sample.bin ! vaapiparse_h265 ! "video/x-h265, stream-format=(string)byte-stream" ! vaapidecode ! checksumsink2 frame-checksum=FALSE file-checksum=TRUE Let me know how many streams have different checksum than the reference checksums with you guys :)
All samples (114/115) except DELTAQP_A_BRCM_4.bin has correct checksum now, git head : cf097e60c7eeb0b8edb581434819460d1c2fd9a3 By the way, did you test DELTAQP_A_BRCM_4.bin with vaapi-intel-driver using something else than gstreamer-vaapi??? If so, What was the checksum you got for this stream?
Just an update: There is a very interesting synchronization issue(i think) in driver which is causing visual artifacts (which is not reproducible with any video rendereres other than vaapisink).. I will update more about this later.
Closing this as fixed for now. Please create new report if you find more streams having checksum-mismatch issue.