The VideoLAN team released version 2.1.2 of their VLC player today.
This is a maintenance release, “fixing a numerous number of bugs and regressions introduced in 2.1.0, notably on audio device management and SPDIF/HDMI pass-thru“. The 2.1.2 release also “allows experimental decoding of HEVC and Webm/VP9” video, according to the release notes.
In my vlc.SlackBuild I have not only upgraded the VLC source, but additionally updated the internal libraries for bluray, dvdnav, dvdread, ffmpeg, fribidi, live555, opus, speex and x264. I also enabled the 10-bit decoder for H.264 video (also known as High 10 Profile or Hi10P) which should please the Anime fans out there. I really thought I had done this way back already, but apparently not so for VLC 2.1.x.
My next mission is to find out what’s wrong with hardware decoding of the video. Either I get a complete crash of the application (mp4 files) or the picture is all jerky and blocky (mkv files). With the parameter “-avcodec-hw no” added to the vlc commandline I can watch any video without issues (Nvidia binary driver on multilib slackware64-current with libva-0.32.0 installed… perhaps I should use the same version of libva as I use internally in VLC, which is libva-1.2.1).
Where to find my new VLC packages:
- http://slackware.com/~alien/slackbuilds/vlc/ (only containing the versions that do not violate US patents). Mirrored at http://taper.alienbase.nl/mirrors/people/alien/slackbuilds/vlc/ .
- http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/ (alternative repository containing packages capable of AAC/MP3 encoding and encrypted DVD playback).
Rsync acccess is offered by the mirror server: rsync://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/ .
My usual warning about patents: versions that can not only DEcode but also ENcode mp3 and aac audio can be found in my alternative repository where I keep the packages containing code that might violate stupid US software patents.
Thanks Eric! VLC seems to be my favorite media player.
Hi, Eric!
First of all, thanks for all of your awesome packages! 🙂
Now, about hardware decoding…
Why don’t you just re-enable VDPAU support by default?
Reading your VLC.SlackBuild, I discovered that you disabled it for compatibility reasons. Are these issues still there, even after 4 years?
I think installing just libvdpau (from SBo maybe) should be enough to successfully compile VLC, even without proprietary driver installed.
With VDPAU enabled, supported hardware could use it along with their own drivers, while unsupported ones could fallback to VA-API, using external libva and libva drivers.
What do you think? Am I making it too easy?
I would really like to use VLC with VDPAU, since VA-API has always had very bad performance on my system, an old laptop with Nvidia m8600GT.
At this time, I’m using MPlayer with VDPAU enabled, and it’s way better than VLC+VA-API. While decoding h264 high-res videos, my CPU usage is about 1-3% with MPlayer, and about 20-30% with VLC. Kinda weird.
Do you have acceptable performance with VLC and VA-API?
Thanks again!
Hi!
I am occasional video watcher, but I have impression that std x.org drivers aren’t capable to do anything close to ATI/NVIDIA proprietary drivers. My expereince ir based on laptop having ATI Mobility HD5940 – with x.org’s drivers processor load is awful and video is jerky
Hi thraphyx,
You made me think about your comment regarding VDPAU support.
Actually I disabled VDPAU in the ffmpeg libraries, because VLC did not have support for VDPAU until recently. Support was added only since the 2.1.0 release.
So I decided to add a VDPAU driver to the SlackBuild and indeed, VLC picked it up when recompiling.
I tested the resulting package and indeed, perfect picture and no crashes.
To be honest, before adding VDPAU support I built new packages for libvdpau, libva and libva-vdpau-driver and installed those to see what difference those made. It actually cured the jerky blocky video in my MKV test file but still crashed VLC in the MP4 test file. The added VDPAU support did the trick and I can now play any video with GPU-supported hardware decoding.
I will upload packages for Slackware 14.1 as soon as I finish rebuilding for both ARCH-es and restricted/unrestricted (still 4 big packages).
Eric
Hi Eric,
I’m trying to play rtmp streams in vlc and I can’t get it to work.
I tried the windows version of vlc and it plays the rtmp link.
Any ideas?
Thanks, keep up the great work! 🙂
The new package (2) doesn’t work correctly for me (package version 1 worked for me).
When i try to play an h264 video i get this.
“No suitable decoder module:
VLC does not support the audio or video format “h264″. Unfortunately there is no way for you to fix this.”
Btw i’m using amd.
To clarify more i can’t play any video at all (xvid, wmv, h264 and so on).
Audio works but not video.
Yeah… the issue is that the new package links dynamically against libvdpau now.. it should have used static linking:
[0x7f0cd0c75158] main decoder warning: cannot load module /usr/lib64/vlc/plugins/codec/libavcodec_plugin.so’ (libvdpau.so.1: cannot open shared object file: No such file or directory)
I will see how I can fix that in the next release, for now you can fix this by installing my libvdpau package.
Eric
Greg, I never play rtmp streams so I would not know. Got an URL?
Eric
Hi,
Here is a link to try:
rtmp://videocdn-us.geocdn.scaleengine.net/jblive/live/jblive.stream
Installing libvdpau-0.7-x86_64-1alien.txz made it work.
Greg, Me
I had no idea that RTMP support was broken… it must have been for a long time.
The good news is, I fixed both your issues. My new VLC package can play RTMP streams _and_ it no longer breaks if you don’t have libvdpau installed.
The first of the 4 packages is ready (it’s what I tested with) and when the three remaining ones have been built for Slackware 14.1/current, I will upload them.
Eric
Thanks Eric. 🙂
Thank you very much, Eric!
However the CPU load is a little bit lower now, but it’s not the huge improvement I expected. I suspect that it’s something related to post-processing, which I can’t figure out how to disable.
Seems that VLC full vdpau support (including post processing and rendering) is implemented in the development 2.2 branch.
So, I think I just have to wait.
Anyway, awesome work as always! Thanks again! 😀
Eric, it’s me again! 🙂
The libva-vdpau-driver package for Slackware64-14.1 misses the driver libraries. It has been built with a wrong SlackBuild which doesn’t apply the two
patches.
All other versions look good, so I think it was just a small oversight.
I just rebuilt the package using the files in build/ directory and now it’s all OK.
Hi thraphyx
I can not find any missing driver libraries in the libva-vdpau-driver package for Slackware64-14.1. The compile will not even succeed when you do not apply those patches.
What driver libraries got built additionally when you recompiled?
And what was the difference in CPU usage before and after?
Eric
Hi Eric,
Actually the compile will fail without patches, but the package will be built, even without libraries (and with libraries, I mean *all* libraries driver). It’s strange, I know. I faced this a while ago while trying to compile liba-vdpau-driver-0.7.4 myself, before finding the two patches.
Anyway, after a further investigation, I found that issue is related to your sbrepos repository. There are two packages for libva-vdpau-driver, a .tgz and a .txz.
The .txz does indeed contain libraries, while the .tgz doesn’t. And slackpkg automatically picks up the faulty .tgz.
This issue is present in all your Slackware64-14.1 repo:
http://taper.alienbase.nl/mirrors/people/alien/sbrepos/14.1/x86_64/libva-vdpau-driver/ (the mirror I use)
http://www.slackware.com/~alien/sbrepos/14.1/x86_64/libva-vdpau-driver/
http://www.slackware.com/~alien/slackbuilds/libva-vdpau-driver/pkg64/14.1/
After downloading and installing the correct libva-vdpau-driver-0.7.4-x86_64-1alien.txz package, vainfo now shows installed drivers, like using the package I rebuilt myself.
However, with a 720p h264 mkv, VDPAU it’s a little bit better than VA-API, but VLC CPU usage is still around 20-25%.
The strange thing is that MPlayer with VDPAU uses around 3% while playing the same file. Even with a 1080p h264 mkv file, MPlayer rarely exceed 7-8% of CPU usage.
I reserve to do more tests with VLC and MPlayer.
What are your CPU usage with VLC? Do you have better performance with VDPAU than VA-API?
Actually, building of libva-vdpau-driver fails with:
make[1]: Entering directory /tmp/build/tmp-libva-vdpau-driver/libva-vdpau-driver-0.7.4/src’
CC vdpau_driver.lo
In file included from sysdeps.h:24:0,
from vdpau_driver.c:21:
config.h:111:29: error: redefinition of ‘__vaDriverInit_0_31’
#define VA_DRIVER_INIT_FUNC __vaDriverInit_0_31
^
vdpau_driver.c:312:10: note: in expansion of macro ‘VA_DRIVER_INIT_FUNC’
VAStatus VA_DRIVER_INIT_FUNC(void *ctx)
^
vdpau_driver.c:287:10: note: previous definition of ‘__vaDriverInit_0_31’ was here
VAStatus __vaDriverInit_0_31(void *ctx)
^
make[1]: *** [vdpau_driver.lo] Error 1
I think, that’s why there are no drivers in tgz package.
I tried it on Slack64-14.1. both patches are applied
Hi thraphyx,
I have removed that spurious .tgz package immediately, it was an earlier failed attempt which I had forgotten to remove. Thanks for finding this!
I get roughly two-thirds the CPU usage when I play videos in VLC with VDPAU enabled, compared with unaccelerated playback. That is worse than I would expect.
Thanks Eric it works without libvdpau package now 😀
I appreciate your hard work.
Hi,
thanks a lot for your continued work on VLC, LibreOffice and KDE — I use them also on my parents’ laptop (32 bit; Thinkpad T60): works great! Thank you!
lems