Bug 83965 - [SNB|IVB|BYT|HSW|BDW Regression][Media][Decode]SSIM value is low when doing AVC/MPEG2/VC1/VP8 decoding test
Summary: [SNB|IVB|BYT|HSW|BDW Regression][Media][Decode]SSIM value is low when doing A...
Status: CLOSED NOTABUG
Alias: None
Product: libva
Classification: Unclassified
Component: intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Gwenole Beauchesne
QA Contact: Sean V Kelley
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-17 06:40 UTC by zhixinx.liu
Modified: 2014-09-24 01:51 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

Attachments

Description zhixinx.liu 2014-09-17 06:40:07 UTC 
SSIM value is low  when doing decoding test. AVC/MPEG2/VC1/VP8 decoding test can reproduce this issue. All fail cases caused by one commit(c27d56290a150b44a87ba2d2df4d0c36ca5ab218).
1. Testing Steps:
========================================================================
1.run command "LD_PRELOAD=/tests/media_tools/i965_drv_video_hook_op.so mplayer -nosound -fps 30 -vo vaapi -va vaapi /media/h264/SVA_CL1_E.264"
2.run command "ldecod.dbg.exe -i /media/h264/SVA_CL1_E.264 -o SVA_CL1_E.264.ref.yuv"
3.judge two YUV file from above command, get the ssim.
e.g.
filename  Y SSIM extreme Y SSIM average U SSIM extreme U SSIM average V SSIM extreme V SSIM average  
 SVA_CL1_E.264 0.275827 0.349745 0.922072 0.935353 0.902785 0.916374

2. Bisect Information:
========================================================================
c27d56290a150b44a87ba2d2df4d0c36ca5ab218 is the first bad commit
commit c27d56290a150b44a87ba2d2df4d0c36ca5ab218
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Tue Aug 26 14:14:54 2014 +0200
    Report BUSY surface state accordingly.
    Return VA_STATUS_ERROR_SURFACE_BUSY for key interfaces.
    This covers for va{Get,Put}Image(), as originally mandated by the
    VA-API specs; vaBeginPicture() as this is the entry-point to any
    decode, encode or video processing operation; but also for plain
    vaMapBuffer() operation.
    Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
    (cherry picked from commit 62bfb507c8512af6529ee794848155bd7cd97fc6)

3. Testing Env:
========================================================================
Libva: (master)e0d25ece01e7aba819c910e98c4fb4706cdab055
Libva_intel_driver: (master)238d8077705711036d62a6d536311def3ef35035

4. Frequency of Occurence:
========================================================================
100%
Comment 1 Gwenole Beauchesne 2014-09-19 09:32:01 UTC 
Most likely a tool problem. i.e. i965_drv_video_hook_op.so. I have just completed a run with MVT, and all tests pass just fine. Please get your tool fixed. We will close this issue as INVALID.

Zhixin, things to look out in your tool: make sure you call vaUnmapBuffer() before the VA surface is to be used again. e.g. before you exit from the vaPutSurface() hook.

I also remind you that hooking on vaPutSurface() is still a wrong thing to do. There are plenty of other correct approaches to work with.
Comment 2 zhixinx.liu 2014-09-24 01:49:54 UTC 
It's a tool problem. The derived image should be deleted after dumping YUV data, otherwise it will block other functions.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.