Bug 93758 - mpv + st/va: add motion adaptive deinterlacing v2 = segfault/assert
Summary: mpv + st/va: add motion adaptive deinterlacing v2 = segfault/assert
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-18 16:10 UTC by Andy Furniss
Modified: 2016-01-21 08:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
segfault (3.64 KB, text/plain)
2016-01-18 16:10 UTC, Andy Furniss
Details
assert (3.79 KB, text/plain)
2016-01-18 16:10 UTC, Andy Furniss
Details
Possible fix (1.06 KB, patch)
2016-01-18 19:57 UTC, Christian König
Details | Splinter Review

Description Andy Furniss 2016-01-18 16:10:28 UTC
Created attachment 121110 [details]
segfault

Testing st/va: add motion adaptive deinterlacing v2 on tonga.

Release or git mpv segfaults or asserts (mesa --enable-debug).

mpv --hwdec=vaapi --vo=vaapi --vf=vavpp:deint=motion-adaptive ...
Comment 1 Andy Furniss 2016-01-18 16:10:57 UTC
Created attachment 121111 [details]
assert
Comment 2 Christian König 2016-01-18 19:57:18 UTC
Created attachment 121120 [details] [review]
Possible fix

Hi Andy,

stupid typo, does the attached patch fix the issue?
Comment 3 Andy Furniss 2016-01-18 20:48:01 UTC
(In reply to Christian König from comment #2)
> Created attachment 121120 [details] [review] [review]
> Possible fix
> 
> Hi Andy,
> 
> stupid typo, does the attached patch fix the issue?

Yes that fixes it thanks.

I can see there are more artifacts than with vdpau m/a deint - I was expecting them to use the same underlying code and so have the same artifacts?
Comment 4 Andy Furniss 2016-01-20 22:02:00 UTC
(In reply to Andy Furniss from comment #3)

> I can see there are more artifacts than with vdpau m/a deint - I was
> expecting them to use the same underlying code and so have the same
> artifacts?

After looking at more samples it seems that sometimes parts of one of the fields ends up with old content being displayed/not updated.

This is more than a few extra artifacts - it's buggy. With vdpau there were artifacts, but you wouldn't notice them watching normally (would need to pause/slow mo). Given the right input this is instantly noticeably corrupt.
Comment 5 Christian König 2016-01-21 08:58:32 UTC
(In reply to Andy Furniss from comment #4)
> (In reply to Andy Furniss from comment #3)
> 
> > I can see there are more artifacts than with vdpau m/a deint - I was
> > expecting them to use the same underlying code and so have the same
> > artifacts?
> 
> After looking at more samples it seems that sometimes parts of one of the
> fields ends up with old content being displayed/not updated.
> 
> This is more than a few extra artifacts - it's buggy. With vdpau there were
> artifacts, but you wouldn't notice them watching normally (would need to
> pause/slow mo). Given the right input this is instantly noticeably corrupt.

Really interesting. I can't see of hand how this could happen.

The only possibility is that the input bitstream somehow gets corrupted sometimes and because of that UVD fails to decode the field in question. But that would affect normal playback as well.

Anyway, please open up a new bug report for this. Clearly a separate issue.


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.