Bug 79520 - mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
Summary: mpv 0.3.10-1 shows no video after mesa and ati-dri update to version 10.2.0rc5-1
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-02 02:25 UTC by Savyasachee Jha
Modified: 2014-06-07 15:36 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
The console output of mpv when I play an mp4 file (7.20 KB, text/plain)
2014-06-02 02:25 UTC, Savyasachee Jha
Details

Description Savyasachee Jha 2014-06-02 02:25:35 UTC
Created attachment 100260 [details]
The console output of mpv when I play an mp4 file

Hello, I'm on Arch Linux with the [testing] repository enabled. The version of mesa, mesa-libgl and ati-dri in [testing] is 10.2.0rc5-1 whereas the ones in extra are 10.1.4-1.

Description:
After updating the ati-dri mesa-libgl and mesa packages to 10.2.0rc5-1 (in [testing]), there is no video in mpv even though there is audio output. Downgrading to the versions in [extra], i.e. to 10.1.4-1 causes this to be rectified. I tried compiling mpv-git with the new packages installed, but it did not work either.

Additional info:
I've included the console output and am providing the link to my mpv config file. If it helps, the output of lspci | grep -i VGA is:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Park [Mobility Radeon HD 5430/5450/5470]

Steps to reproduce:
Upgrade the mesa, mesa-libgl and ati-dri packages to the latest ones in [testing] and run mpv on any video with the given config.

Link to config: https://github.com/genghizkhan91/dotfiles/blob/master/mpv/config
Comment 1 Michel Dänzer 2014-06-02 06:57:13 UTC
Can you bisect Mesa?
Comment 2 Savyasachee Jha 2014-06-03 05:26:31 UTC
(In reply to comment #1)
> Can you bisect Mesa?

I can, but (this sounds almost shameful to admit) I can't find which commit marks the 10.1.4 release. I bisected it at the commit 03a0471832a9d336741bca194873e8c8185245fe (it talks about adding a news item related to 10.4.1), but running LD_LIBRARY_PATH="./src/glx" LIBGL_DRIVERS_PATH="./lib/gallium/" mpv <file-name> gave me the same error.

If you can give me the requisite commit, I will bisect it at the proper place and then try this again. Not being a coder, or even someone who uses git regularly, I apologise if this is too basic a question to be asked.
Comment 3 Michel Dänzer 2014-06-03 06:08:37 UTC
(In reply to comment #2)
> I can, but (this sounds almost shameful to admit) I can't find which commit
> marks the 10.1.4 release.

The tag mesa-10.1.4 points to commit cc9b282f8a00c1d8e552a3776709ca84e1f4467d .
Comment 4 Savyasachee Jha 2014-06-03 15:59:57 UTC
So I bisected mesa. The steps are:

$ make clean && make distclean

$ ./autogen.sh --prefix=/usr --sysconfdir=/etc --with-dri-driverdir=/usr/lib/xorg/modules/dri --with-gallium-drivers=r300,r600,radeonsi,swrast,svga --with-dri-drivers=r200,radeon,swrast --with-egl-platforms=x11,drm, --enable-llvm-shared-libs --enable-gallium-egl --enable-gallium-llvm --enable-gallium-gbm --enable-egl --enable-gbm --enable-shared-glapi --enable-glx --enable-glx-tls --enable-dri --enable-osmesa --enable-gles1 --enable-gles2 --enable-texture-float --enable-xa --enable-vdpau --enable-omx --enable-opencl --enable-opencl-icd--with-clang-libdir=/usr/lib && make

$ LD_LIBRARY_PATH="./src/glx" LIBGL_DRIVERS_PATH="./lib/gallium/" mpv <file-name>

for every bisection. The end result was:

ee978aee94d98fec669002eb5ef7ceb1f46683a9 is the first bad commit
commit ee978aee94d98fec669002eb5ef7ceb1f46683a9
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Jul 15 09:16:22 2013 -0600

    vl: add H264 encoding interface

    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Leo Liu <leo.liu@amd.com>

:040000 040000 4e0bb4d3cba505fb01e24188353c3b05a4be201c 2e24ff49402d12d9865e6ef2dcb9771580bc4b8e M      src

I should add, that for every time I marked something as bad in the bisection, I would get a "zsh: segmentation fault (core dumped)" message without fail. The ones I marked as good ran perfectly.
Comment 5 Christian König 2014-06-04 06:39:55 UTC
(In reply to comment #4)
> ee978aee94d98fec669002eb5ef7ceb1f46683a9 is the first bad commit
> commit ee978aee94d98fec669002eb5ef7ceb1f46683a9
> Author: Christian König <christian.koenig@amd.com>
> Date:   Mon Jul 15 09:16:22 2013 -0600
> 
>     vl: add H264 encoding interface
> 
>     Signed-off-by: Christian König <christian.koenig@amd.com>
>     Signed-off-by: Leo Liu <leo.liu@amd.com>

This is really stange, since the patch you bisected doesn't touch any of the VDPAU or OpenGL states in question.

Can you try mesa master as well?

Thanks,
Christian.
Comment 6 Savyasachee Jha 2014-06-04 07:03:37 UTC
(In reply to comment #5)
> This is really stange, since the patch you bisected doesn't touch any of the
> VDPAU or OpenGL states in question.
> 
> Can you try mesa master as well?
> 
> Thanks,
> Christian.

I just tried it with the latest master. The steps remain the same. The output was:

zsh: segmentation fault (core dumped)  LD_LIBRARY_PATH="./src/glx" LIBGL_DRIVERS_PATH="./lib/gallium/" mpv

The error number was 139.
Comment 7 Christian König 2014-06-04 08:29:25 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > This is really stange, since the patch you bisected doesn't touch any of the
> > VDPAU or OpenGL states in question.
> > 
> > Can you try mesa master as well?
> > 
> > Thanks,
> > Christian.
> 
> I just tried it with the latest master. The steps remain the same. The
> output was:
> 
> zsh: segmentation fault (core dumped)  LD_LIBRARY_PATH="./src/glx"
> LIBGL_DRIVERS_PATH="./lib/gallium/" mpv
> 
> The error number was 139.

Can you get the backtrace of the segmentation fault?
Comment 8 Savyasachee Jha 2014-06-04 08:41:05 UTC
(In reply to comment #7)
> Can you get the backtrace of the segmentation fault?

To get that, I'd normally have to compile mesa with CFLAGS="-g" make. Will that work here too? Or is there any other way to do it? (Sorry, I'm not a programmer myself.)
Comment 9 Christian König 2014-06-04 08:50:39 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Can you get the backtrace of the segmentation fault?
> 
> To get that, I'd normally have to compile mesa with CFLAGS="-g" make. Will
> that work here too? Or is there any other way to do it? (Sorry, I'm not a
> programmer myself.)

Instead of fiddling with the CFLAGS you should probably better use "--enable-debug" for configure.
Comment 10 Savyasachee Jha 2014-06-04 10:45:18 UTC
(In reply to comment #7)
> Can you get the backtrace of the segmentation fault?

I ran it through gdb (commit number: ee978aee94d98fec669002eb5ef7ceb1f46683a9):

[vader ~/Builds/cleandir/mesa]% systemd-coredumpctl gdb
TIME                                         PID   UID   GID SIG EXE
              Wed 2014-06-04 18:44:36 JST  22401  1000   100  11 /home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2bf64f50/testbuild/testprog
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2bf64f50/testbuild/testprog...done.
[New LWP 22401]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/home/vader/Builds/mpv-git/src/mpv/build/.conf_check_b4d8c0b22f0a39cf01e84c4b2b'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f0e85fcd452 in ?? () from /usr/lib/liblua.so.5.2
Comment 11 Emil Velikov 2014-06-04 12:27:02 UTC
FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH will not work. The libvdpau library is hardcoded to search for /usr/lib/vdpau/${driver}_vdpau.so.

There are two ways around this - rebuild libvdpau with this commit [1] and set VDPAU_DRIVER_PATH or symlink/install the library.

[1] http://cgit.freedesktop.org/~aplattner/libvdpau/commit/?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
Comment 12 Savyasachee Jha 2014-06-04 12:33:43 UTC
(In reply to comment #11)
> FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> will not work. The libvdpau library is hardcoded to search for
> /usr/lib/vdpau/${driver}_vdpau.so.
> 
> There are two ways around this - rebuild libvdpau with this commit [1] and
> set VDPAU_DRIVER_PATH or symlink/install the library.
> 
> [1]
> http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2

I'm using the vo=opengl option in mpv.
Comment 13 Christian König 2014-06-04 12:34:51 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> > will not work. The libvdpau library is hardcoded to search for
> > /usr/lib/vdpau/${driver}_vdpau.so.
> > 
> > There are two ways around this - rebuild libvdpau with this commit [1] and
> > set VDPAU_DRIVER_PATH or symlink/install the library.
> > 
> > [1]
> > http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> > ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
> 
> I'm using the vo=opengl option in mpv.

Yeah, but you are using the VDPAU hardware acceleration.
Comment 14 Savyasachee Jha 2014-06-04 12:39:29 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > FYI if you're using VDPAU, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> > > will not work. The libvdpau library is hardcoded to search for
> > > /usr/lib/vdpau/${driver}_vdpau.so.
> > > 
> > > There are two ways around this - rebuild libvdpau with this commit [1] and
> > > set VDPAU_DRIVER_PATH or symlink/install the library.
> > > 
> > > [1]
> > > http://cgit.freedesktop.org/~aplattner/libvdpau/commit/
> > > ?id=ee9491a1216f47e10cbb551391a01c7fcde940d2
> > 
> > I'm using the vo=opengl option in mpv.
> 
> Yeah, but you are using the VDPAU hardware acceleration.

Ah. Okay, I got it. I need to leave this particular laptop right now, so I can't do that atm. I'll have it done tomorrow. Thanks for all the help and the patience.
Comment 15 Christian König 2014-06-04 15:42:46 UTC
Ok that sounds like you updated the OpenGL packages, but not VDPAU right?

Well in this case the reason it doesn't work any more is that OpenGL advertises OpenGL/VDPAU interop, but the VDPAU driver actually isn't new enough end rejects the export request.

Try the --hwdec=no option on mpv.
Comment 16 Savyasachee Jha 2014-06-05 04:15:22 UTC
(In reply to comment #15)
> Ok that sounds like you updated the OpenGL packages, but not VDPAU right?
> 
> Well in this case the reason it doesn't work any more is that OpenGL
> advertises OpenGL/VDPAU interop, but the VDPAU driver actually isn't new
> enough end rejects the export request.
> 
> Try the --hwdec=no option on mpv.

You're right about that. It works perfectly with the --hwdec=no option. In the Arch repos, we have libvdpau 0.7. From what I can tell, that is the latest version out there in the wild as well.

In any case, I recompiled libvdpau from git (the current master) and installed it, but the problem persists.
Comment 17 Savyasachee Jha 2014-06-07 14:46:52 UTC
Okay, after upgrading to mesa, mesa-libgl and ati-dri 10.2.1, there's been no problem. Thanks for all the help!


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.