Also next week, there will be a release of KDE SC 4.4.5 (the last in the 4.4 series) and if everything goes as planned, this should end up in slackware-current – meaning, I won’t have to build packages for 4.4.5.
VideoLAN team has released version 1.1.0 of their VLC player.
This release has many improvements over the previous 1.0.0 version of this “swiss army knife of media players“.
A detailed description of the changes can be found in the team’s announcement of the new release. You can also have a look at the supported features of the player.
Slackware packages are available for you: http://www.videolan.org/vlc/download-slackware.html . I’ll be happy with feedback from you, if you are using my package. Please note that you do not have to install any other package if you use mine. There are no package dependencies (except for libdvdcss which you have to install additionally if you want to watch “encrypted” DVDs – which means almost all DVDs).
Please note that the VideoLAN developers have decided to deprecate all older versions of their player. This means that as soon as a vulnerability is discovered in releases before 1.1.0, this vulnerability will not be patched and you will be urged to upgrade to 1.1.0 (or later) instead.
This decision was made because the developer team is currently stretched thin and is unable to maintain more than one stable and one development branch.
In past posts, I talked a bit about video decoding in VLC, particularly using the GPU (your graphics card’s processor) to decode frames instead of letting the software do all the work. My previous posts mostly revolved around the fact that this did not yet work in the release candidates of VLC 1.1.0 (which will hopefully be released soon).
There is good news however! Last weekend, the bug in VLC was fixed which made the player crash as soon as the VAAPI functions were called. My updated packages (32-bit and 64-bit) for vlc-1.1.0-rc3 are available now, with the patch included, and indeed I have no more crashes. Get those new RC3 packages and enjoy!
So, what is this GPU supported hardware decoding of video and why is it beneficial?
High Definition video has become a de facto standard on the internet, and lots of home video recorders save in HD format too. Playback of a HD video on your computer will stretch the limits of what your CPU can do… resulting in stuttering playback (dropped video frames) or display artefacts because the CPU can not keep up.
This is where the Video Acceleration API (VAAPI) originally drafted by Intel, and adopted by other hardware vendors (Nvidia and Ati of course) comes into play. VAAPI is a software interface which provides access to hardware accelerated video processing, using your computer’s GPU which is very much suited for computationally intensive operations. For instance, owners of a Nvidia graphics card will notice that VAAPI-supported HD playback will drop the CPU usage from 100 to 30 or less percent.
My VLC package supports VAAPI hardware acceleration, if you add the following package(s):
libva: your computer will at least need this one. This is the library which exposes the VA API and adds the driver which VLC will use if your graphics card is an Intel one.
vdpau-video: this is only needed if your graphics card is an Nvidia. Vdpau is Nvidia’s own acceleration API and this package adds a VDPAU backend to libva.
xvba-video: this is only needed if you own an Ati-powered graphics card. This package adds a XvBA backend to libva. Unfortunately (for you) I do not own an Ati card, so I can not compile this software into a Slackware package. Get the sources here and compile them yourself, after you installed my libva package.
I should mention one caveat:
It depends on your hardware, how good the support for GPU-accelerated video processing is. An Intel card can only accelerate MPEG-2 video, whereas Nvidia and Ati cards will also support acceleration for MPEG-4/H.264/VC-1 video formats. Note that hardware-acceleration is not limited to HD video. VAAPI will for instance be beneficial to Atom-powered netbooks too, their Intel graphics will allow fluent full-screen playback of DVDs in VLC with low CPU usage, thereby saving your battery.
You can easily determine what your card’s capabilities are. After installing libva, run the “vainfo” command and examine the output. This is what my T410 laptop reports:
libva: libva version 0.31.0-sds6
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA API version: 0.31
vainfo: Driver version: i965 Driver 0.1
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
You’ll notice that there are a few updated dependencies and one new package, libdbusmenu-qt. Grab those too! There are no pre-compiled language packs for now (I just lacked the time), but I have added the sources and updated the build script for “KDEI” so you can easily build a single package yourself. For example, compile the “nl” language pack with this command:
# PKGLANG=nl ./kde-l10n.SlackBuild
Good luck! Don’t forget to report the bugs you find at http://bugs.kde.org/ and feel free to discuss them in the comments section of this post.
By the time KDE4.5 sees its first Release Candidate, I will have updated the Qt4 package too. At this moment I did not want to diverge too much from Slackware 13.1.
Although it seems (by looking at the changelog between 4.4.3 and 4.4.4) that there were no spectacular updates in the latest stable KDE Software Compilation, I got some feedback that 4.4.4 does feel “snappier” than the 4.4.3 which is part of Slackware 13.1.
Good news (that people actually use my packages)!
It made me think again about the upcoming KDE SC 4.5 for which the second beta was released very recently (the sources at least). I had not really planned on a Slackware build for KDE 4.5 until I had access to the stable sources, which will not happen all too soon.
But if even a small (bugfix) upgrade is received so positively, some people may find it interesting or challenging enough to get their hands dirty with the new beta release. So I decided to move ahead, locate the updated and new dependencies and start building packages.
At this moment there are no kdepim packages planned for KDE 4.5. The kdepim developers decided that the current quality of their software is not high enough to be included in KDE 4.5 – they expect kdepim to be re-integrated into KDE SC 4.5.1 and will release preview versions on their own in the meantime.
The software requirements for 4.5 are not yet written down like they are for older releases, but after reading through the mailing lists I have a feeling that I will have to upgrade Qt to 4.7 in the end. There is no such Qt release yet… so at some point I will start using source snapshots from the Qt git repository.
Not right now however, because the compilation recognized my already installed Qt 4.6.2 and did not complain about that. Tonight I will finish a 64-bit build of KDE SC 4.4.85 (aka 4.5-beta2) and install that to my laptop. If that does not break everything, I will also build a set of 32-bit packages and release the lot to my “ktown repository“.
Let me know if you are interested in tying out the beta! If there is no interest, I may leave it at just the 64-bit packages and use the time to debug my VLC package (which seems to crash on VAAPI support).
Watch this space for more news, soon (I hope).
Dear visitor, you seem to be using an Ad Blocker. Please consider whitelisting 'Alien Pastures'. I use the revenue from displaying ads (small as it is) to keep this site running. Thanks!