Bug 58875 - [ilk] h.264 decoding broken / visual errors
Summary: [ilk] h.264 decoding broken / visual errors
Status: RESOLVED FIXED
Alias: None
Product: libva
Classification: Unclassified
Component: intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) All
: medium major
Assignee: haihao
QA Contact: Sean V Kelley
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-30 01:14 UTC by Tobias Jakobi
Modified: 2013-01-04 08:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
picture showing an example of image corruption (362.13 KB, image/png)
2012-12-30 09:50 UTC, Tobias Jakobi
Details
naive fix for the issue (1.43 KB, text/plain)
2012-12-30 11:50 UTC, Tobias Jakobi
Details

Description Tobias Jakobi 2012-12-30 01:14:34 UTC
Hello,

I recently updated the vaapi/intel-driver from 1.0.17 to 1.0.19, but I'm not experiencing issues with hw-accelerated MPEG2 decoding. From time to time garbled bars appear in the picture, mostly when scene changes occur. So I presume it has something to do with reference picture decoding.

Anyway, I checked and it seems that the issues was introduced from 1.0.17 to 1.0.18 (read: the issue also appears with 1.0.18).

The CPU is a Intel Core i5 M 450, so the GPU should be an Arrandale IIRC.

I'm using xf86-video-intel-2.20.15 as DDX and mplayer-vaapi (built from sources) as player. The source is a BluRay (How to Train Your Dragon).

Rendering is done via the Xv backend.

Greets,
Tobias
Comment 1 Tobias Jakobi 2012-12-30 01:15:31 UTC
"but I'm not" <- this should of course read "but I'm _NOW_"
Comment 2 Tobias Jakobi 2012-12-30 02:58:58 UTC
Ah, sry, another correction needed: The stream is H264, and _not_ MPEG2.

Can a admin please change the title?
Comment 3 Tobias Jakobi 2012-12-30 09:50:30 UTC
Created attachment 72289 [details]
picture showing an example of image corruption

I also updated intel-driver to git, since there were some changes concerning H264. Not fixing anything though.
Comment 4 Tobias Jakobi 2012-12-30 10:27:23 UTC
More corrections. I wasn't really awake then I entered the bug:

The issue is introduced between 1.0.16 and 1.0.17. I also did a proper bisect this time, and the faulty commit is:

h264: fix scan for bit offset to macroblock (4bbfe67d2098f4f2aaeb3c5ab2cd930d2acb1c26)
Comment 5 Tobias Jakobi 2012-12-30 11:50:58 UTC
Created attachment 72301 [details]
naive fix for the issue

So this is how I (naively) fixed the issue for now. No idea if this is correct at all, but it removes the image corruption completly for me.
Comment 6 haihao 2013-01-04 02:49:02 UTC
Pushed. Thanks for your patch.
Comment 7 Gwenole Beauchesne 2013-01-04 05:00:15 UTC
Hi, what version of mplayer-vaapi (and FFmpeg) were you using?

BTW, n == (i - j) :)
Comment 8 haihao 2013-01-04 05:55:10 UTC
The fix is needed for the following case:

xx xx 00 00 03 aa bb cc

'aa' is the last byte of slice_header.
Comment 9 Tobias Jakobi 2013-01-04 08:08:34 UTC
(In reply to comment #7)
> Hi, what version of mplayer-vaapi (and FFmpeg) were you using?
It's built from the latest checkout of the gitorious repo. You remember that your build script forces a specific ffmpeg version?


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.