SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Your /var/log/Xorg.0.log and/or glxinfo might have revealing details as well. Some hypothesis are nouveau with accel disabled or something connected to the wayland stack if you do indeed have that?
Code:
21:30 <imirkin> it means that either VDPAU_DRIVER=nvidia is set, or the DRI2 X extension is not working properly to return the 'nouveau' name.
21:31 <orbea> according to the person who experienced it, VDPAU_DRIVER is not set at all, so it must be the latter
21:32 <imirkin> perhaps wayland without Xwayland?
21:32 <imirkin> (or perhaps it doesn't work properly with Xwayland? i really don't know that stack)
21:33 <orbea> maybe, he shouldn't have wayland, but it wasn't all that clear what he did or did not have...
21:35 <imirkin> could be nouveau with accel disabled
21:35 <imirkin> in which case you don't get DRI2
21:36 <orbea> is there a way to check that?
21:36 <imirkin> xorg log would be pretty revealing. or glxinfo.
21:37 <orbea> i'll pass that on
Edit: For glxinfo you may need LIBGL_DEBUG=verbose
For example:
Code:
LIBGL_DEBUG=verbose glxinfo | grep -i dri
libGL: pci id for fd 4: 10de:100a, driver nouveau
libGL: OpenDriver: trying /usr/lib64/xorg/modules/dri/tls/nouveau_dri.so
libGL: OpenDriver: trying /usr/lib64/xorg/modules/dri/nouveau_dri.so
libGL: Using DRI3 for screen 0
As I use SMPlayer, which plays this same video perfectly, I was unaware of any
problems with MPlayer.
After reading through this thread I tried MPlayer and, as said in the first post,
it plays the audio, but not the video, but in this case the empty black box
remains on the screen.
As previously mentioned this same video plays as it should in SMPlayer.
This is on a week old installation of -current from an .iso, and updated to the moment, plus the NVidia driver version 384.69.
It seems to work fine on 14.2 but I do build locally all the dependencies and ffmpeg 3.2.7 non-redistributable, not using the internal ffmpeg.
MPlayer 1.3.0-5.3.0 seems fully compatible with external ffmpeg 3.2.x still not sure about 3.3.x version though. Anyway, there's a ~/mplayer/config
Code:
# Write your default config options here!
vo=vdpau
[vo.vdpau]
vc=ffh264vdpau,ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffhevcvdpau,ffodivxvdpau,
If you write the config like that, it will use correct video output without having to pass a vo=vdpau every time.
I think smplayer does bypass the mplayer config file, and only checks what's set in smplayer preferences.
Code:
libavformat version 57.56.101 (external)
libavcodec version 57.64.101 (external)
Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU))
Note: I've tested on both nvidia 340.x and xf86-video-nouveau-1.0.15 that I built from -current source.
It's libvdpau-1.1.1 version without any patches, works most of the time with 5% CPU.
On the same machine, xv output needs to use 20% CPU.
Here's what I have so far. In a stock vanilla Slackware{64}-current installation, running gmplayer from a terminal is broken. Running mplayer by itself works, but complains about a DRI error so it can't prescale the video (720x480 widescreen stays anamorphic and isn't normalized). If I run gmplayer with -vo sdl, everything works because the prescaling is done in the software.
In analyzing the logs, I found that nouveau can't identify the GPU chipset (Nvidia GTX 1050 ti), so it doesn't create /dev/dri/card0. On the other box, nouveau identifies the GPU (Nvidia GT 730), creates the nodes and everything works.
Granted, this is on a stock partition only intended as a "buildbox" partition, but I think this is still a significant issue that nouveau can't seem to properly identify the Nvidia GP10x series chipsets (the GTX 1050 ti is in that family). (The kernel identifies it properly, though.)
I am marking this thread solved, even though there are still some intermittent issues with MPlayer not always playing the video (just giving a black window). This may be because of some other extra multimedia packages I have installed, but that's for another thread.
After some digging, I found that the 4.9 kernel does NOT support the GT{X} 10 series (Pascal) GPU's. It identifies it, but does not support it. Support was not introduced until the 4.12 kernel. I built the latest kernel (4.12.10) and installed it, and lo and behold everything works. It even loads the firmware the card needs, which happens to already be in Pat's kernel-firmware package.
Since the 4.12 kernel is not LTS, I'm not going to ask Pat to upgrade to it. Besides, there is still one Geforce GPU it doesn't support yet, and that support may not come until the 4.14 kernel, which is supposed to be the next LTS release (problably around November).
I seem to have the same problem here with an old GeForce GTX 650 and nVidia drivers from Slackbuilds. I'm seeing the black screen with both mplayer and mpv (self compiled) with vdpau. Both work with the xv and gl drivers. I also get the message about the DRI error. DRI seems to be enabled:
Code:
$ grep DRI /var/log/Xorg.0.log
[ 47.903] (II) NVIDIA(0): [DRI2] Setup complete
[ 47.903] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia
However this doesn't return anything:
Code:
$ LIBGL_DEBUG=verbose glxinfo | grep -i dri
Everything used to work fine until I run an upgrade a few days ago. I believe this rules out a kernel support problem for me.
$ mplayer -vo vdpau VID-20170429-WA0001.mp4
MPlayer SVN-r37953-7.2.0 (C) 2000-2017 MPlayer Team
225 audio & 464 video codecs
Playing VID-20170429-WA0001.mp4.
libavformat version 57.81.100 (internal)
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55e9fc2037e0]Protocol name not provided, cannot determine if input is local or a network protocol, buffers and access patterns cannot be configured optimally without knowing the protocol
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang eng
VIDEO: [H264] 378x400 24bpp 25.000 fps 463.5 kbps (56.6 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 57.104.101 (internal)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Clip info:
major_brand: isom
minor_version: 512
compatible_brands: isomiso2avc1mp41
title: 289671711468198
encoder: Lavf56.40.101
Load subtitles in ./
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 20.0 kbit/0.71% (ratio: 2499->352800)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [vdpau] 378x400 => 1850x1957 Planar YV12
A: 3.0 V: 3.0 A-V: -0.001 ct: 0.001 0/ 0 1% 6% 0.7% 0 0
Exiting... (Quit)
Hmm, the DRI problem is not consistently reproducible across reboots, and I don't know how to trigger it. When DRI works (as above), mpv works with vdpau but mplayer gives me a black screen. When DRI doesn't work / stops working (?) then both mpv and mplayer give me black screens.
I'd probably start a new topic as this doesn't seem to be related to the original post. When you do, include the above text I requested, as well as the output from mpv/mplayer when the issue arises.
Can you also provide the output of mplayer -v -vo vdpau VID-20170429-WA0001.mp4 in that thread to see if verbose gives us any helpful output?
The above video might be a bad example. Here are logs from a different one (namely a local copy of this), which seems to run into a DRI problem. It doesn't work with either mplayer or mpv with the vdpau driver.
Please let me know if you still want me to start a new thread with all this.
The above video might be a bad example. Here are logs from a different one (namely a local copy of this), which seems to run into a DRI problem. It doesn't work with either mplayer or mpv with the vdpau driver.
I'm not seeing any issues beyond the error "[VD_FFMPEG] DRI failure.", and a quick google search didn't turn up anything obvious. Maybe someone who is more familiar with the Nvidia driver can help out.
Quote:
Originally Posted by lcd047
Please let me know if you still want me to start a new thread with all this.
I'd still suggest it. You aren't getting the same error as the OP and with the thread being marked as [SOLVED], others may not come in to try and help with your problem.
BTW, when you do open your new thread, do you see any errors with mpv or is it just the same error? If there are errors, post those as well.
Also, you don't need to use dropbox unless it is a lot of code. You can paste it right into the thread using [code][/code] tags like you did earlier. I know it is easier for me to read and I don't have to load up a new tab (especially since many of those sites are blocked at my work), but I'm not sure how other forum members prefer it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.