1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

XBMC's Thoughts On XvBA: AMD Catalyst Has Problems

Peter Frühberger

Published on 21 June 2012
Written by Peter Frühberger
Page 2 of 2 - 28 Comments

We have a large number of users running our packages on an everyday basis. The latest testing builds also include VDPAU support, so Nvidia users that seek more performance and other improvements can easily test the latest master branch changes.

Many dedicated community members build packages for Opensuse, Arch linux, Debian and others. One of our early adopters was Openelec. Openelec 2.0 with its large user base will be released with an Xvba implementation directly based on our latest code.

In only five to six months sparetime work, we created a stable and to date unmatched experience for all AMD htpc users out there. Sounds too good to be true? Yeah, kind of as the future is totally unclear.

Let's continue with the dark side. What is not working for now? Basically everything we are awaiting from AMD since mid December. AMD did not update their xvba-sdk and there were no driver improvements regarding video decoding, e.g. faster decoding times. Therefore, feature wise we are exactly at the point we started from. Currently only standard files(e.g. Bluray) up to H264@High Level 4.1 are supported, that means: no more than 4 reframes at a resolution of 1920x1080 are decoded correctly. If you want to decode files with a higher level (5.0 or 5.1) and a large number of reframes you only see some kind of pixel mash. This is something we get complaints about at least twice a week. Most users cannot believe that in 2012 such a feature is just missing within a driver. In a nutshell, AMDs hardware platform is still held back on linux by its driver and API support.

Everytime we try to get into official contact, we are told that AMD was working on it and everything was nearly done. We are hearing this for approximately half a year now from AMD, but were never given a timeline. We are still waiting for H264@High Level 5.1 and Mpeg-2 Bitstream support, which is really important for DVB users, as a lot of live TV content is currently transmitted in this format. While we are at it - how about Mpeg-4/Divx support? In short: The same features available on Microsoft Windows for years.

Our sources say that these features are implemented in fglrx since a long time, but simply not activated within the driver. Nobody seems to know why.

But, we also have good news from AMD. We got into contact with a fglrx beta tester, that was willing to test our xvba implementation with early AMD Beta drivers. Some bugs reported directly to him got fixed within the latest 12.6 Beta release of fglrx, namely some ASIC hangs and the HDMI audio issue, which was a big showstopper for general Linux htpc users. But this situation is also not as fine as it could be. There are no plans on release cycles, there are no changelogs, there is no active bugtracker. Also dropping driver support for older hardware - which you can still buy everywhere - has not improved users trust in AMD.

We are looking forward to get Mpeg-2 support implemented and hope that AMD will give public news on how to enable the H264 Level 5.1 Profile. After this, we will push Xvba support into the offical xbmc repository (great review time). When our ffmpeg changes are accepted into XBMC mainline, we can send them upstream (ffmpeg itself) to help enable Xvba hardware support in all other movie players within the OSS world. All the other improvements developed and improved during our Xvba testings are pushed to upstream at the moment.

Let's hope that the new AMD Linux Crew Survey will improve the collaboration with OSS users. A good way to let them know about the bugs standing out.

We are often asked about what hardware users should buy. The answer is not that easy. We came into contact with many AMD Fusion users with mostly E-350 and E-450. But yeah, if you see all the stuff that is not working and no one other than AMD can do something about it, it is a difficult decision. If you only look at the features available now and you want to invest into a power saving X86, small and highly integrated htpc at a reasonable price, nvidia with their approx 3 years old ION-2 is still the better choice on Linux platforms. Another choice is VAAPI on Intel Hardware that made a lot of progress in the past months, it is a pretty good alternative now. We really hope that AMD fixes these outstanding issues - for now it is like the famous novel of Samuel Beckett - Waiting For Godot. We hope that AMD Xvba is coming to another end.

Greetings,
Complete Xvba Implementing Team

Update: For those not familiar with the state of Linux video acceleration, read this article.

Latest Articles & Reviews
  1. Samsung 850 EVO SSD Linux Benchmarks
  2. Kubuntu 15.04 Is Turning Out Quite Nice, Good Way To Try Out The Latest KDE
  3. 5-Way Linux Distribution Comparison On The Core i3 NUC
  4. OCZ ARC 100 Linux SSD Benchmarks
  5. Lenovo ThinkPad X1 Carbon Works Great As A Linux Ultrabook
  6. Transcend SSD370 256GB
Latest Linux News
  1. HTC & Valve Partnered Up For The Steam VR Headset
  2. 8cc: A Small C11 Compiler
  3. Not Everyone Likes The Possible "VULKAN" Name For Next-Gen OpenGL
  4. The Binary Blobs Making Up Coreboot
  5. Linux 4.0 & LLVM vs. GCC Yielded Much Interest This Month
  6. XBMC/Kodi 15.0 Alpha 1 Released
  7. Xfce 4.12 Released After Nearly Three Years Of Work
  8. The Khronos Group Filed A Trademark On "Vulkan" API
  9. Mozilla Thunderbird Adoption Climbs, Thunderbird 38 In May
  10. The Most Popular Linux Benchmark Results On OpenBenchmarking.org
Most Viewed News This Week
  1. Linux 4.0-RC1 Tagged, Linux 4.0 Will Bring Many Notable Improvements
  2. Screenshots Of The GNOME 3.16 Changes
  3. More Proof That Allwinner Is Violating The GPL
  4. The Tremendous Features Of Fedora 22
  5. Krita 2.9 Released, Their Biggest Release Ever
  6. Linux 4.0 Doesn't Have The Weirdest Codename
  7. A Single UEFI Executable With The Linux Kernel, Initrd & Command Line
  8. Canonical Comes Up With Its Own FUSE Filesystem For Linux Containers

Close Advertisement

Close Advertisement