Bug 93760 - radeonsi vaapi mpeg2 decode slightly corrupt or asserts.
Summary: radeonsi vaapi mpeg2 decode slightly corrupt or asserts.
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-18 16:41 UTC by Andy Furniss
Modified: 2019-09-25 17:53 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
assert (3.26 KB, text/plain)
2016-01-18 16:41 UTC, Andy Furniss
Details
lock hung task trace (2.10 KB, text/plain)
2016-01-18 16:42 UTC, Andy Furniss
Details

Description Andy Furniss 2016-01-18 16:41:56 UTC
Created attachment 121114 [details]
assert

I mentioned in a mail that I noticed mpeg2 vaapi decode was slightly corrupt - more noticeable on some samples than others.

While testing with mesa built with --enable-debug I can't even run - getting an assert.

FWIW I am currently on an unstable agd5f drm-next with pp on and while running a non asserting mesa to look at the corruption I just hard locked - just luck I guess as powerplay does sometimes lock - but I got a trace, which doesn't always happen so attaching that as well.

The dirty is patches from -

https://bugs.freedesktop.org/show_bug.cgi?id=93721
Comment 1 Andy Furniss 2016-01-18 16:42:55 UTC
Created attachment 121115 [details]
lock hung task trace
Comment 2 Andy Furniss 2017-01-13 15:16:11 UTC
Time moves on - I can't actually lock (so far) testing now, but output is still corrupt.
Comment 3 Christian König 2017-01-13 16:17:17 UTC
Sorry totally missed that bug.

The problem is most likely that GStreamer sends multiple slices in one request to VA-API and we can't handle that in the state tracker.

Should be easy to fix actually, but we need somebody to look into it and reproduce this.

Another task for Nayan maybe?
Comment 4 Nayan Deshmukh 2017-01-13 17:34:17 UTC
I can reproduce the issue. I will look more into this over the weekend and also read more about VA-API.
Comment 5 Andy Furniss 2017-01-13 17:50:14 UTC
(In reply to Christian König from comment #3)
> Sorry totally missed that bug.
> 
> The problem is most likely that GStreamer sends multiple slices in one
> request to VA-API and we can't handle that in the state tracker.

Though it seems gstreamer also has issues, I only first tried it today.
This bug is testing with mpv.
Comment 6 Nayan Deshmukh 2017-01-16 14:48:37 UTC
(In reply to Christian König from comment #3)
> Sorry totally missed that bug.
> 
> The problem is most likely that GStreamer sends multiple slices in one
> request to VA-API and we can't handle that in the state tracker.
> 
> Should be easy to fix actually, but we need somebody to look into it and
> reproduce this.
>
What changes do we need to make to handle multiple slices?
The video plays fine with vdpau. Can you point me to the code where vdpau handles multiple slices as both of them share similar code path.

> Another task for Nayan maybe?
Comment 7 Christian König 2017-01-16 15:11:49 UTC
Take a look at vlVaHandleSliceParameterBufferMPEG12 and the assert.

We probably just need to handle the case of multiple buffers here and in handleVASliceDataBufferType.

The later is a bit tricky, since you need to search all slice buffers for the start code and call begin_frame() only once even when you get multiple buffers and/or calls to that function.
Comment 8 Nayan Deshmukh 2017-01-28 16:46:22 UTC
(In reply to Christian König from comment #7)
> Take a look at vlVaHandleSliceParameterBufferMPEG12 and the assert.
> 
> We probably just need to handle the case of multiple buffers here and in
> handleVASliceDataBufferType.
> 
> The later is a bit tricky, since you need to search all slice buffers for
> the start code and call begin_frame() only once even when you get multiple
> buffers and/or calls to that function.

mpv only send a single slice when it should be sending 36 which it does in case of VDPAU, as of now we can handle multiple slices, though not as efficiently as we like it to be.
Comment 9 GitLab Migration User 2019-09-25 17:53:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1227.


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.