Bug 87054

Summary:	VDPAU decoding mostly fails with Assertion `0' failed. (r600g, Radeon HD 8570D)
Product:	Mesa	Reporter:	Kertesz Laszlo <laszlo.kertesz>
Component:	Drivers/Gallium/r600	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Kertesz Laszlo 2014-12-06 18:57:13 UTC

Building recent mesa git i found that most video players that use VDPAU 
hardware decoding fail with

vl/vl_stubs.c:45:vl_video_buffer_formats: Assertion `0' failed.
Trace/breakpoint trap

for example trying to play a 1080p h264 video that worked with hw 
decoding before:

$ mpv /media/bigdata/Videos/1080ptestvideo.mp4
Playing: /media/bigdata/Videos/1080ptestvideo.mp4
[stream] Video (+) --vid=1 (*) (h264)
[stream] Audio (+) --aid=1 --alang=und (*) (aac)
File tags:
 major_brand: mp42
 minor_version: 0
 compatible_brands: isommp42
 creation_time: 2012-09-10 21:27:25
Trying to use hardware decoding.
AO: [alsa] 44100Hz stereo 2ch float
vl/vl_stubs.c:45:vl_video_buffer_formats: Assertion `0' failed.
Trace/breakpoint trap


It happens to mpv and xbmc, but interestingly NOT to vlc (built with 
VDPAU support) when using (or attempting to use) hardware decoding. 
With hw decoding off all work.
Only player that can use VDPAU is vlc built from git.

The vl_stubs.c file is referenced in one commit,

http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/auxiliary/vl/vl_stubs.c?id=f093c1c8ec1bce50d9338533ce775b564358fbeb

auxiliary/vl: add galliumvl_stub.la

Tried to revert it and didnt work.

I use Debian Testing 64 bit with kernel, drm, mesa, llvm built from git.
Now i have  last commit a28ad9d4c0d4b95aee8c3b99e9aaa59add21ea9d in my current build of mesa, kernel 3.18.0-rc7-00057-gebea76f.

Comment 1 Andy Furniss 2014-12-06 19:39:51 UTC

Probably this one -

https://bugs.freedesktop.org/show_bug.cgi?id=86837

Comment 2 Kertesz Laszlo 2014-12-06 20:16:31 UTC

Might be. But on my system mpv segfaults too with vdpau and mplayer shows no video (the latter may be somewhat different issue).

Comment 3 Andy Furniss 2014-12-06 21:08:15 UTC

(In reply to Kertesz Laszlo from comment #2)
> Might be. But on my system mpv segfaults too with vdpau and mplayer shows no
> video (the latter may be somewhat different issue).

Yea, I can get mpv to segfault also - when I initially tested I used 

... --hwdec=vdpau --vo=vdpau ...

which still works as it's "pure" vdapu, with current mpv ommiting the --vo=vdpau makes it use opengl for vo and I guess the  nv_vdpau_interop that is causing the problem.

Todays mplayer still works for me.

Comment 4 Kertesz Laszlo 2014-12-06 22:18:53 UTC

(In reply to Andy Furniss from comment #3)
> (In reply to Kertesz Laszlo from comment #2)
> > Might be. But on my system mpv segfaults too with vdpau and mplayer shows no
> > video (the latter may be somewhat different issue).
> 
> Yea, I can get mpv to segfault also - when I initially tested I used 
> 
> ... --hwdec=vdpau --vo=vdpau ...
> 
> which still works as it's "pure" vdapu, with current mpv ommiting the
> --vo=vdpau makes it use opengl for vo and I guess the  nv_vdpau_interop that
> is causing the problem.
> 
> Todays mplayer still works for me.

Well seems that you are right. I re tested with mpv and works.
I really dont know what caused the issue since i had in ~/mpv/config:

vo=vdpau
hwdec=auto
hwdec-codecs=h264,vc1,wmv3,mpeg2video,mpeg4

before and it crashed. Maybe for some reason it didnt take the vo option or something. It still crashes if use vo=opengl but after changing it back to vdpau it started working.
This and the fact that mplayer exhibits other issues (something related to avcodec missing h264 decoding) leads me to think that this bug is indeed duplicate of 86837.

Comment 5 Kertesz Laszlo 2014-12-06 22:19:26 UTC


*** This bug has been marked as a duplicate of bug 86837 ***

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.