GNOME Bugzilla – Bug 731831
the ssim value is low when doing AVC conformance test
Last modified: 2014-07-03 06:32:30 UTC
after using gstreamer 1.2, when decoding AVC, the ssim value is low. using mplayer to decode same file, cannot find this issue. e.g: filename Y SSIM extreme Y SSIM average U SSIM extreme U SSIM average V SSIM extreme V SSIM average SVA_NL2_E.264 0.882641 0.993097 0.990970 0.999469 0.992171 0.999539 17 17 1 1. Testing Env: ======================================================================== kernel: 3.15.0-rc8_drm-intel-fixes_223a6f_20140617 X11R7: { Libdrm: (master)libdrm-2.4.54-9-g8fc62ca8ac010659023bb63c4759eb683de4f9af Mesa: (10.2)8c319b3f9818e711654cf440e6f6899a99c077ad Xserver: (server-1.15-branch)xorg-server-1.15.1-5-g268eb961c9c58fc7cc26e514661b5f8304c1c08f Xf86_video_intel: (master)2.99.912-68-ge5b94c2d9b29b78432aa72049934e365a2913710 Libva: (master)ce3315accf067115fbe22a13bf8689bab01da778 Libva_intel_driver: (master)745340dd013399f64507de73401ab3adb712dad5 Ffmpeg: (master)61df0819d49ba831948681a7e8aa1a6def26b1a9 Mplayer: (hwaccel-vaapi)1923fa10ed77bbf8408f2ce312d85a97dab1f0f3 Glib: (master)7991178a752a22274950e54dc4f05b55ae54d756 Gstreamer10: (1.2)8b9a8e4fb0c1cfb91f23d21d7b7dce86fea7232f Gst_plugins_base10: (1.2)4c31880bf0a4b720ab90fc8753fbbcc72275d6f8 Gst_plugins_good10: (1.2)2dbd9d948dc35dfd6b63f3fc7b79a8b0d6c66c07 Gst_plugins_bad10: (1.2)277b8c34e7214177764833b73f17e43ced496f8f Gst_plugins_ugly10: (1.2)2233d97e6ad1a3988d9a9ca0fc0cf00ec4031a8f Gst_plugins_vaapi10:(master)5e5d62cac79754ba60057fc2516135aad8d7de35 } 2. Testing Steps: ======================================================================== 1.running cmd "gst-launch-1.0 filesrc location=/media/SVA_NL2_E.264 ! vaapiparse_h264 ! vaapidecode ! vaapisink sync=false" to get yuv file 2.running cmd "ldecod.dbg.exe -i SVA_NL2_E.264 -o ref.yuv" to get reference yuv file 3.compare two yuv file to get SSIM 3. Frequency of Occurence: ======================================================================== 100%
commit abfb5dd06cc7cdfa920707fc8f5553f81014e5e3 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Wed Jun 18 13:47:36 2014 +0200 vaapidecode: parse source data until a frame is obtained. Parse any pending data until a complete frame is obtained. This is a memory optimization to avoid expansion of video packets stuffed into the GstAdapter, and a fix to EOS condition to detect there is actually pending data that needs to be decoded, and subsequently output. https://bugzilla.gnome.org/show_bug.cgi?id=731831
the AVC conformance test pass rate has improvement with this patch(pass number:63->88). but not good enough. compare the test result: without_patch with_pathch gstream1.0 Pass:63 Pass:88 Pass:168 TEST ENV: Libva: (master)ce3315accf067115fbe22a13bf8689bab01da778 Libva_intel_driver: (master)745340dd013399f64507de73401ab3adb712dad5 Ffmpeg: (master)e7fc5d53a02c07e75a2254839a452e1cbf830d3a Mplayer: (hwaccel-vaapi)1923fa10ed77bbf8408f2ce312d85a97dab1f0f3 Glib: (master)7991178a752a22274950e54dc4f05b55ae54d756 Gstreamer10: (1.2)8b9a8e4fb0c1cfb91f23d21d7b7dce86fea7232f Gst_plugins_base10: (1.2)4c31880bf0a4b720ab90fc8753fbbcc72275d6f8 Gst_plugins_good10: (1.2)daf888a6d80af3d64c5618470e2b12111b7657e3 Gst_plugins_bad10: (1.2)277b8c34e7214177764833b73f17e43ced496f8f Gst_plugins_ugly10: (1.2)2233d97e6ad1a3988d9a9ca0fc0cf00ec4031a8f Gst_plugins_vaapi10: (master)1a2c06a81cb7d78609b99b5906f528070da9cad6
What file precisely? This looks strange.
It would also help to try with the original h264parse too. :) + a variation around: { vaapiparse_h264 or h264parse } ! video/x-h264,alignment=nal or alignment=au
It would also help to regression test since last week report did not mention anything. Thanks.
fail case for example: filename Y SSIM extreme Y SSIM average U SSIM extreme U SSIM average V SSIM CABREF3_Sand_D.264 0.451516 0.978491 0.725861 0.989249 0.662973 0.986783 BANM_MW_D.264 0.895072 0.998951 0.991121 0.999911 0.984765 0.999848 CAFI1_SVA_C.264 0.717134 0.991680 0.933710 0.998050 0.934400 0.998071 LS_SVA_D.264 0.913978 0.999949 0.979752 0.999988 0.984318 0.999991 CAPCM1_Sand_E.264 0.740667 0.991356 0.943343 0.998111 0.943526 0.998118 ......
Can you change your original pipeline with: h264parse ! video/x-h264,stream-format=byte-stream,alignment=nal ! vaapidecode ! [...] ? I mean, in your framework. and run again with alignment=au Thanks.
total case number 168, pass number with alignment=nal and alignment=au alignment=nal alignment=au 86 89
as fail so many cases. change the severity from normal to critical.
with gstream 1.0 build env, cannot build the latest gstream vaapi. the error message is: gsth264parse.h:107:3: error: unknown type name 'GstAdapter' GstAdapter *frame_out; make[4]: *** [libgstvaapi_parse_la-gstvaapiparse.lo] Error 1 with gsteam 1.2 build env, build gstream vaapi with commit:e8fe78824bc65a2b1f5166d2aa34099af6aaec4b (when use this commit and gstream1.0 branch, it cannot find this issue) after build done. run these test case, also can find this issue. SO maybe it's not gstream vaapi's issue. just becase of upgrade the gstream version from 1.0 to 1.2.
Yes, I think I see the possible fix to GstVideoDecoder implementation in GStreamer 1.2.
All current patches for h264parse have been pushed to the local gstreamer-vaapi tree.
with gst-plugin_base10's patch(0001-videodecoder-parse-source-data-until-a-frame-is-obta.patch), the pass rate increased. pass rate: 1. stream-format=avc,alignment=au 168/168 (100.0%) 2. stream-format=byte-stream,alignment=nal 148/168 (88.09%) 3. stream-format=byte-stream,alignment=au 162/168 (96.42%) Test Command: gst-launch-1.0 filesrc location=/tmp/AVCfile ! h264parse ! video/x-h264,stream-format=avc,alignment=au ! vaapidecode ! vaapisink sync=false gst-launch-1.0 filesrc location=/tmp/AVCfile ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=nal ! vaapidecode ! vaapisink sync=false gst-launch-1.0 filesrc location=/tmp/AVCfile ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! vaapidecode ! vaapisink sync=false as most of the test case has passed, so change the severity from critical to normal.
using vaapiparse_h264 to reset these test case. the pass rate is: 1. stream-format=avc,alignment=au 168/168 (100.0%) 2. stream-format=byte-stream,alignment=nal 166/168 (88.09%) 3. stream-format=byte-stream,alignment=au 168/168 (100.0%) Test Command: gst-launch-1.0 filesrc location=/tmp/AVCfile ! vaapiparse_h264 ! video/x-h264,stream-format=avc,alignment=au ! vaapidecode ! vaapisink sync=false gst-launch-1.0 filesrc location=/tmp/AVCfile ! vaapiparse_h264 ! video/x-h264,stream-format=byte-stream,alignment=nal ! vaapidecode ! vaapisink sync=false gst-launch-1.0 filesrc location=/tmp/AVCfile ! vaapiparse_h264! video/x-h264,stream-format=byte-stream,alignment=au ! vaapidecode ! vaapisink sync=false
Hi Zhixin, About the "2. stream-format=byte-stream,alignment=nal 166/168 (88.09%)", I guess there should be a calculate mistake for the value 88.09%. Please correct me. Thanks Focus
As of gstreamer-vaapi e6cdacee65f221e4c464cff5cc5f2bbb74a75146, there is no more failures. Please try with vaapiparse_h264 in both AVC and MVC tests + the GstVideoDecoder patch.
All AVC & MVC decode tests now fully pass in all 3 combinations now. so close it.