Linux XBMC + AMD Catalyst Omega 14.12
#1
Hi,

I know xbmc does not officially support the catalyst drivers, but there have been some major changes in the 14.12 release. (vaapi support, ...)

Regarding the prefered Radeon OSS driver, I have the problem that I use an AV Receiver between my HTPC and my TV. I also connect a chrmecast to the receiver, which only uses the limited color space for hdmi (YCbCr or RGB 16-235). This is usually the standard for HDMI devces like BlueRay Players. But the Radeon OSS only supports RGB Full 0-255. My TV also has much better Black Values with YCbCr (Yes black level is also set up in the TV). So I was always looking for a way to have video hardware accelaration and proper HDMI Color Space.

Radon OSS: proper VAC, no YCbCr
Catalyst <14.12: no or bad VAC but all Color Spaces (Pixel Maps in CCC)

Now, the Catalyst 14.12 still supports all Color Spaces AND has VAAPI support. XVBA was dropped by AMD.

So I installed all 14.12 fglrx*.deb packages from AMD on my Xubuntu 14.04 system. This works flawlessly. After installing all vaapi packages, vainfo shows me that a lot of stuff is supported on my system (sorry not at home, no output).

I changed the XBMC video settings from my old vdpau setting to vaapi settings and turned on a mpeg2 TV channel. I can see that a ff-mpeg-vaapi codec is used, which is nice, BUT:

I continuously have one of my cpu 4 cores at 100% AND I only have BOB for deinterlacing.


So now I have nice black levels and a better supported Color Space for my Home Cinema/TV Setup, but other drawbacks.

I read that a newer libva version has motion adaptive deinterlacing at lest for intel cpus. So I updated my system with the ppa:wsnipex/vaapi. So vaapi was upgraded from 1.3 to 1.4. but no improvement in case of cpu and deinterlacing,

Anyone else who encountered these problems or has at least tried the new driver? There is not much information at the moment about this topic.

----
System:
XBMC 13.2
Xubuntu 14.04 fully updated
ppa:wsnipex/vaapi
AMD Catalyst Omega 14.12
AMD A8 5... APU
Reply
#2
Having the same problem with one CPU core at 100% usage. Disabling vSync fixes that problem but I know that is not the solution. Generally CPU usage goes down considerably when vSync is disabled. Didn't notice any major picture breakage or stuttering. My dad is glued to the TV all the time (Breaking Bad) so I'll check deinterlacing later when I have a chance.

Arch Linux
A6-5400 APU
Reply
#3
Nice to know, someone else is facing these issues.

I will try to disable vSync in CCC and look at the CPU this evening. I was happy I have vSync now without the need of compton in XFCE.

I Only have BOB and BOB(interlace as deinterlacing, but these two hav this flickering problem. Basically the picture jumps up and down a litle bit. nicely to observe at channel logos.
Reply
#4
Yes, dear people.

History repeats again. AMD _cannot_ do vsyncing correctly. Every time you enable vsync that will happen. This is a bug that is more than 2.5 years old. And more than 2 years since I reported that to AMD.

File bugreports with that damn Catalyst fglrx driver. We won't do a single thing to support that utter crap, especially when AMD closed source department _exactly_ knows the issue.

Stick with the OSS drivers.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#5
XVBA was not dropped at all.

VAAPI is a wrapper (!) in driver to use XVBA (It's basically the old xvba-va-driver, but pushed a level down and shipped with fglrx). It's the same crap from the time around we implemented XVBA directly. Furthermore they did it wrong, it's still not threadsafe. Helix multithreading architecture will just make the driver hang.

Fglrx is a no, a no and another no.

Don't use it.

Here, see, search for XVBA:
http://pastebin.com/UkScakeN

Code:
Thread 27 (Thread 0x7fffa63e9700 (LWP 26261)):
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007ffff619780a in _L_lock_55 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007ffff6197781 in __lll_lock_elision (futex=0x7fffa8012540, adapt_count=<optimized out>, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-lock.c:94
#3  0x00007fffa4b3a42d in XvbaDeviceContainer::ContainerLock() () from /usr/lib/libAMDXvBA.so.1
#4  0x00007fffa4b5d0e0 in VASurface::Sync() () from /usr/lib/libAMDXvBA.so.1
#5  0x00007fffa4b575c6 in VAContext::BeginFrame(unsigned int) () from /usr/lib/libAMDXvBA.so.1
#6  0x00007fffa4b5c48d in VABeginPicture () from /usr/lib/libAMDXvBA.so.1
#7  0x00000000016c700f in ?? ()
#8  0x0000000900000008 in ?? ()
#9  0x00000000016c7197 in ?? ()
#10 0x00007fffa63e8764 in ?? ()
#11 0x23bd2ea3da530600 in ?? ()
#12 0x0000000000000000 in ?? ()

Btw. those issues are already reported to AMD and I also wrote them how to fix it. Furthermore I told them you to implement post processing within two lines. But it won't happen, they just don't work with us and ignore us until the end of time.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#6
I'd like to stick with the OSS radeon driver, but it does not support limited Color Space. ONLY RGB 0-255, which totally sucks for HDMI Home theater Setups!

If radeon would support YCbCr everything would be fantastic and I would stick with it.
-----

At least now fglrx 14.12 supports a lot more codecs with vaapi. The old xvba-va wrapper only supported 2 cases as far as I remember.

-----
The problem is, both drivers have major NOGOs for HTPCs, but sadly I already have the AMD hardware.
Reply
#7
You can choose OSS radeon, but set xbmc's output to Limited Range (Expert Settings of Video Output).
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#8
Yeah their VAAPI now supports mpeg2, mpeg4, vc1, h264. The old wrapper based on xvba 0.74 did only VC1, h264.

So, now you get GPU offloading and 100% CPU load cause of the vsync bug :-) not funny.

Btw. can you get me:

ls -l /dev/dri/card0

does this exist with fglrx?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#9
I'll do that as soon as I'm home.

-----

XBMC Limited Range is only for XMBC. As soon as I use the HTPC e.g. for surfing, I have the same color range problem again.So it is also a compromise.

----

Do you have any idea why radeon OSS does not support RGB Studio limited and YCbCr 4:4:4 and 4:2:2?
Reply
#10
Cause it's not implemented. -> bugs.freedesktop.org and ask for that feature, it should be doable quite easily.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#11
http://people.freedesktop.org/~cbrill/dr...2013-12-02 <- I talked with Alex Deucher some months ago, currently trying to get the status on it.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#12
Something from Alex:

Code:
18:20 < fritsch> agd5f: mmh?
18:20 < fritsch> agd5f: that's not the answer to my Limited Range question
                 right? :-)
...
18:38 < fritsch> agd5f: how can I do that?
18:38 < fritsch> agd5f: is it possible via xrandr?
18:39 < fritsch> cause our users most of the time complain if their TV is only
                 limited range
18:39 < fritsch> and browser etc. don't have a chance to switch to that mode
18:39 < fritsch> something like: xrandr --output HDMI-0 --set "RGB BroadCast"
                 "Limited"
18:39 < fritsch> "Full" would be nice
18:44 < agd5f> fritsch, not implemented at the moment
18:44 < fritsch> agd5f: oki. Can I write that somewhere on a long wishlist?
18:45 < agd5f> sure :)
18:45 -!- tomboy65 [~tomboy@gateway/tor-sasl/tomboy64] has quit [Ping timeout:
          250 seconds]
18:53 < fritsch> agd5f: where is you favorite place to do so?
18:59 < agd5f> fritsch, just ping me periodically so I don't forget :)

Now just ping him from time to time and it will get implemented.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#13
Thank you very much so far. If he is already working on one of the pixel maps / color spaces, it is probably a good idea to also consider YCbCr 4:4:4 and 4:2:2. Basically these should just be other transformation equations and/or simple filters.

I set up the irc, so I can also bring it up from time to time.
Reply
#14
Yeah, ping him from time to time in IRC and ask :-) (once a week or something), hehe.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#15
Something you should know -> OpenGL does not output YCbCr, so there needs to be done a conversion.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply

Logout Mark Read Team Forum Stats Members Help
XBMC + AMD Catalyst Omega 14.120