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)
Created attachment 51106 [details] Sample showing heavy blocking
Created attachment 51107 [details] Expected result for previous attachment
Created attachment 51108 [details] Sample showing medium blocking
Created attachment 51109 [details] Expected result for previous attachment
Created attachment 51444 [details] [review] patch for implicit weighted prediction on Sandybridge Hi, does the attached patch work for you ?
(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.
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?
(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?
(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
Hi, could you please provide the video again? Thanks.
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.
(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
(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.
I can confirm these patches fix this on both my machines, Core i5 2500 and Pentium G630T, thank you very much! :)
(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 :)
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.