Bug 40820

Summary:	Some videos show block-type artifacts (mplayer/vaapi) (sandy-bridge)
Product:	libva	Reporter:	Da Fox <da.fox.mail>
Component:	intel	Assignee:	Gwenole Beauchesne <gb.devel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	gb.devel, mus.svz
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Sample showing heavy blocking Expected result for previous attachment Sample showing medium blocking Expected result for previous attachment patch for implicit weighted prediction on Sandybridge

Description Da Fox 2011-09-13 01:54:17 UTC

Some, but not all videos show block/square artifacts when played back using hardware acceleration (vaapi). Also in the video's that do show these artifacts they are not visible all the time, and when they appear there may be only a few or many artifacts visible in a given frame. The videos appear fine when using -vo xv or -vo vaapi without -va vaapi.

Link: http://www.mediafire.com/?3s92c5znkiase22
Link is to a small sample clip (28mb, 50sec, hd-ready, anime). This clip demonstrates the three 'types' of artifacts described above. 
In the first few seconds of the clip the video appears normal.
Then there is a flashback, which starts out normal too, but after a scene change there appear heavy blocking artifacts. It is hard to tell if only the color of the blocks if off, or if (some of) the actual contents are wrong too. I'm inclined to say the former is the case (only the color is off).
After the flashback returns to the present time there is some mild blocking (especially evident when the woman turns her her head).

Hardware is Dell XPS 15 (L502x) with:
00:02.0 VGA compatible controller: Intel Corporation Device 0116 (rev 09)
[    13.803] (II) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge
Mobile (GT2)

Software versions:
mplayer: http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/mplayer-vaapi-20110127.tar.bz2
libva: fde78c4488dd65430c9452fba4ca04d9b8f94c18
xf86-video-intel: 04c5a3df02f6f40a904ff4edb927ae6ff0ce6408
mesa: 2154c672b3f2a0f3de7aaacd9260954b9310262a
kernel: 3.0.0 (vanilla)

Comment 1 Da Fox 2011-09-13 02:05:31 UTC

Created attachment 51106 [details]
Sample showing heavy blocking

Comment 2 Da Fox 2011-09-13 02:06:06 UTC

Created attachment 51107 [details]
Expected result for previous attachment

Comment 3 Da Fox 2011-09-13 02:06:31 UTC

Created attachment 51108 [details]
Sample showing medium blocking

Comment 4 Da Fox 2011-09-13 02:07:04 UTC

Created attachment 51109 [details]
Expected result for previous attachment

Comment 5 haihao 2011-09-20 23:38:17 UTC

Created attachment 51444 [details] [review]
patch for implicit weighted prediction on Sandybridge

Hi, does the attached patch work for you ?

Comment 6 Da Fox 2011-09-21 01:13:11 UTC

(In reply to comment #5)
> Created an attachment (id=51444) [details]
> patch for implicit weighted prediction on Sandybridge
> 
> Hi, does the attached patch work for you ?

Yes, the patch seems to work. I no longer see the blocking artifacts in the provided sample video. Thanks for the quick fix :)

ps.
Could you please specify what component to apply any patches to next time? I've spend quite some time figuring out it needed to be applied to vaapi/intel-driver (especially since the intel-driver was recently removed from the libva repository, so that the patched file (gen6_mfd.c) was not actually present in neither the libva repository nor the xf86-video-intel repository). Thanks.

Comment 7 elupus 2011-12-27 13:16:23 UTC

Thought i should chime in and say this also fixes issues which is not as noticable at first, but where the error accumulates until next keyframe. In my case the whole image got gradually brighter and brighter (very slightly) then it snapped back on keyframe.

Any reason this is not applied? Should it be fixed somewhere else perhaps?

Comment 8 mus.svz 2012-01-06 06:34:35 UTC

(In reply to comment #7)
> Thought i should chime in and say this also fixes issues which is not as
> noticable at first, but where the error accumulates until next keyframe. In my
> case the whole image got gradually brighter and brighter (very slightly) then
> it snapped back on keyframe.
> 
> Any reason this is not applied? Should it be fixed somewhere else perhaps?

Completely independently from the VAAPI problem I have from bug #42506, I also noticed something similiar on my other machine. However, for me the image didn't get brighter, but more "reddish" and a little bit blocky and then got back to normal on the next keyframe.
This patch seems to fix this for me as well.

So, same question: any particular reason why this has not been applied yet?

Comment 9 Da Fox 2012-01-10 01:23:33 UTC

(In reply to comment #8)
> (In reply to comment #7)
> > Thought i should chime in and say this also fixes issues which is not as
> > noticable at first, but where the error accumulates until next keyframe. In my
> > case the whole image got gradually brighter and brighter (very slightly) then
> > it snapped back on keyframe.
> > 
> > Any reason this is not applied? Should it be fixed somewhere else perhaps?
> 
> Completely independently from the VAAPI problem I have from bug #42506, I also
> noticed something similiar on my other machine. However, for me the image
> didn't get brighter, but more "reddish" and a little bit blocky and then got
> back to normal on the next keyframe.
> This patch seems to fix this for me as well.
> 
> So, same question: any particular reason why this has not been applied yet?

(IRC log)
Oct 27 10:01:08 __gb__:	dafox, we need to compare with other players/drivers, the bug may be a mix of player and/or driver bug. besides, the proposed patch is a workaround, not a fix

Comment 10 Gwenole Beauchesne 2012-01-29 10:14:37 UTC

Hi, could you please provide the video again? Thanks.

Comment 11 mus.svz 2012-01-31 03:42:22 UTC

I have a sample where you can see both, block artifacts and the "snapping back" on keyframe.

http://www.mediafire.com/?8mxryzxz37mf92r

You can see the color getting back to normal at around 12/13s and some block artifacts around 22s (below the tree).

I originally ripped this file from a Blu-Ray with MakeMKV and then compressed it with:
ffmpeg -i <in> -threads 0 -c:v libx264 -preset medium -crf 19 -c:a copy -c:s copy -map 0 <out>

I noticed that if I compress the file again with the exact same parameters, the problem disappears. Not sure how this makes sense, but I thought it might help.

Comment 12 Da Fox 2012-02-07 02:55:57 UTC

(In reply to comment #10)
> Hi, could you please provide the video again? Thanks.

Here you go :)
http://www.2shared.com/video/JLXFYDFC/vaapi_artifacts.html

Comment 13 Gwenole Beauchesne 2012-03-13 09:36:12 UTC

(In reply to comment #12)
> (In reply to comment #10)
> > Hi, could you please provide the video again? Thanks.
> 
> Here you go :)
> http://www.2shared.com/video/JLXFYDFC/vaapi_artifacts.html

I pushed two fixes to git master branch. There were two bugs:
- weighted prediction indicator was incorrect for Sandy Bridge;
- if implicit weight tables are to be used, the HW miscomputes logWDc.

I am not sure if the latter is a HW bug, but I'd expect that if implicit weight tables are used, the correct derivation values are used instead.

Please test on your other clips. Ivy Bridge and Cedar Trail platforms looked fine on this one.

Comment 14 mus.svz 2012-03-13 09:53:24 UTC

I can confirm these patches fix this on both my machines, Core i5 2500 and Pentium G630T, thank you very much! :)

Comment 15 Da Fox 2012-03-17 09:39:33 UTC

(In reply to comment #14)
> I can confirm these patches fix this on both my machines, Core i5 2500 and
> Pentium G630T, thank you very much! :)

Same here on my laptop :)

Comment 16 Gwenole Beauchesne 2012-03-18 06:56:16 UTC

Pushed to master and v1.0-branch. Thanks.

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.