Raspberry Pi for XBMC, some myths and truths
#1
Heart 
I see a lot of people have trouble assessing whether or not a Rasberry Pi is a viable platform to run XBMC on. Let me try to help and summarize what it can and cant do.

Contrary to what you sometimes read, the Pi can indeed decode 1080p30 high-profile (ie, bluray) stutter free. It will even do 3D. But there are some caveats you should be aware off:

- if your media uses VC1 or Mpeg2 as opposed to h.264, divx, etc, then you need to purchase a license to enable hardware accelerated decoding of these codecs. Prices are €1.45 and €2.89 respectively. http://www.raspberrypi.com/license-keys/

- the Pi is not always fast enough to decode DTS or Dolby Digital 5.1 (AC3) to stereo on the fly, but it has no problems passing through these codecs over HDMI to a DTS or AC3 decoder/receiver. If you have an HDMI receiver (or TV) that allows these audio codecs, you will be fine (the work is done by the AVR decoder). If you dont have that hardware, there isnt too much point in using a DTS track, so if possible, you should select a stereo or AAC track instead. Most DTS/AC3 media will have such an audio track. If your source only has DTS audio, and you dont have a DTS capable receiver, you may have a problem.

*update: I actually tested this with my own library. I dont have straight bluray rips, so the highest bitrate I saw was short bursts around ~30Mbps (h264 1080p23.9 + DTS), and my Pi had no problem playing it while decoding the DTS signal, at least when playing it back from a local drive. While playing the same file over the LAN, the Pi did stutter during the high bitrate peaks. One might think its a bandwith issue (100Mbit), but the Pi can serve the same files to my x86 machines, and they wont stutter. In short: it appears to be a problem when playing big files with DTS over the LAN. Local files from a USB drive seem to be fine, though it may not do full rips with DTS decoding, it may not work with some video formats, its widely reported the Pi struggles decoding DTS, but Ive not been able to reproduce this with local files. YMMV.

If you read somewhere that Pi will stutter playing back 1080p, its almost certainly because the user was unaware of one of the above restrictions. It has given the Pi a reputation it doesnt deserve IMHO. When used properly, 1080p playback is utterly smooth, and I would even say it looks better than on my x86 machine.

One more little known feature of the Pi that deserves highlighting, is its built-in HDMI CEC capability. Unlike any x86 videocard Im aware off, the Pi can send and receive HDMI CEC commands. This allow you to use the remote of another HDMI CEC compliant machine, like TV or AVR to control XBMC. On x86 you can achieve the same only buy purchasing a Pulse-Eight adapter kit. HDMI CEC is also known as Easylink, Vierra Link, BRAVIA Sync, Anynet+, etc.

That said, there are a few other aspects of the Pi that may steer you away from it:

- The Pi has no SPDIF out.
If you can not use HDMI audio, the only other option is analog stereo. As an alternative, you can buy a HDMI splitter that splits audio and video and gives you HDMI video and SPDIF audio (example: http://www.amazon.com/ViewHD-Premium-Aud...to+toslink) , but such a device will cost about the same as the Pi and be about as big. The combination is still rather cheap and small, but no longer as impressively so as the Pi alone.

- The Pi currently has no support for HD audio (TrueHD and DTS-HD/MA), even in passthrough. This is a software issue that might be resolved in the future, but for now, playing a DTS-HD stream will result in a DTS signal on your AVR, and playing TrueHD will probably yield nothing or noise.

- While its GPU and videodecode capabilities are respectable, the CPU of the Pi is slow.
There is no way to sugarcoat it. The CPU is an ARM11 based design, which puts it roughly in the performance ballpark of the iPhone 3G (not 3GS) or HTC Legend. In PC terms, roughly a Pentium 2 – 300 Mhz for those of you old enough to remember. This CPU is considerably slower than the better known ARM Cortex A8 cores found in Samsung Galaxy S1 or iPhone 3GS, and far slower than all the cheap Cortex A9 based android devices you can buy today. Oh and incomparable to even the slowest celeron on the market. You do notice this slowness. Not while playing video, but while using the XBMC GUI, its not quite as buttery smooth and responsive as x86 media centers. If you use simple skins like confluence or Quartz, IMO its completely acceptable, and far from frustrating; but dont expect miracles. If in doubt, I would advice you to watch some video's on youtube and see if it lives up to your expectations. Here is one I just uploaded myself:
http://www.youtube.com/watch?v=Bi9wh0d7vjo


(note that the white screen corruption is mostly solved now)

- The network interface is 100T.
Even using USB to Ethernet adapters, you will still be limited to 100T. It wont do gigabit ethernet.

- It uses Linux
Yeah, it does, but that doesnt mean you have to know anything about Linux. Think of your (smart) tv or AV receiver; it probably runs on Linux too, but its not like you need to use a command line interface or edit text files in VI to use it Smile. Same with openelec. It turns your Pi (or x86 box for that matter), in to a real consumer appliance and almost completely hides the fact there is an OS underneath XBMC. But for those that do know Linux, there is still SSH thank God Smile

- Its not much good as a general purpose PC
XBMC linux distro's are stripped down to the bone. You wont even find a browser. If you intend to use your HTPC for other tasks besides XBMC, like internet, social media, gaming, etc, you want to look elsewhere. Sure, you can dualboot openelec with some more general purpose linux distro for the Pi, but if you can figure that out and think thats an acceptable solution, then you are far more of a geek than me, and not likely to be reading anything in this post you didnt know already.

- The hardware is old, almost obsolete, why not buy a much faster android device?
In the near future, and for XBMC users, the Pi will almost certainly be obsoleted by far more capable hardware (typically designed for Android). Some of them already hardly cost more than the Pi today, while giving you goodies like dual core A9 chips and more adequate IO. Thing is, the Pi is (probably) fast enough, while having the advantage of being very popular among 1+ milion geeks for almost a year now, and as a result, it has a pretty mature software stack. Android devices arent there yet. Im sure they will eventually, so if the time comes to switch to Xios or some other Android device, at least know that thanks to its GPIO interface there are a million other uses for your Pi. Like serving as the brains of a home made pinball machine, a quadcopter, coffee machine, or whatever else you can come up with Smile.

If none of the above issues are show stoppers for you, the Pi will offer you a ridiculously small, cheap ($35-$50 if you count codecs, case, etc) , power efficient (~3,5W!) and surprisingly capable media center.
Reply
#2
DTS and AC3 hardware decoding is actually built into the RPi but not currently available to users due to licencing issues.

DTS is the more important one and last I heard they didn't seem interested in offering per-user licences at a small fee similar to MPEG-2 and VC-1.
Reply
#3
Thank you for putting that all in one place. I wasn't aware of the codecs and was on the fence about one of these things for a second media player.
Home built Solaris 11.1 server, ZFS 4 x 3Tb pool, RAIDZ to 9Tb space.
NFS & SMB shares.
Asrock E350M1 mob with 8G RAM running KODI from a 16G USB stick

HDMI -> Yamaha 5.1 -> 60" Sharp LCD -
AR XSight Color Remote

Happy Wife. Nearly.
Reply
#4
(2013-01-16, 22:56)voochi Wrote: DTS and AC3 hardware decoding is actually built into the RPi but not currently available to users due to licencing issues.

As I understand it, its not like there is a harware DTS decoder in there, but there are features of the audio chip that would enable on the fly DTS decoding without overtaxing the CPU, but this would indeed require a licence, and possibly even a validation procedure. Since its very doubtful this issue will be solved in the very near future, its probably a moot point for end users, thats why i didnt mention it.

That said, it is unclear to me how pure software decoding of DTS is permissible (even if its usually too slow in practice to be useful) while using onchip features to achieve the same is not. Do you know?


Reply
#5
(2013-01-16, 22:58)billyprefect Wrote: Thank you for putting that all in one place. I wasn't aware of the codecs and was on the fence about one of these things for a second media player.
I was one of the first few guys got my hands on RPi (thanks to my Lab) and tried several variant of XBMC, along with several supported OSs. The one I still have is the one with 256Mb of memory. After trying for a while several different things, I concluded that RPi is a great piece of H/W but, (in spite of all the youtube videos) it's still not up to the job for Media Center. At least not according to my liking. Playing media files are still okay (ignoring all the limitations described above and considering the price) but navigation is extremely slow. The quality of playback also didn't impress me at all. I ended up with, due the low power consumption, using it as my Gateway and monitoring server . All my big servers at home now go to sleep (S3) after a certain period of inactivity, keeping RPi on all the time. If I need to access any of the servers from outside, I use RPi to send the WOL to the specific server and login from there. It's just great in that way. Cheers!!

MINIX NEO U22-XJ | Denon AVC-X3800H | KEF Q750 | KEF Q150 | KEF Q250c | KEF Q50a | KEF Kube 10 MIE | LG OLED65G16LA | CoreELEC
Reply
#6
(2013-01-16, 23:33)MacUsers Wrote: I was one of the first few guys got my hands on RPi (thanks to my Lab) and tried several variant of XBMC, along with several supported OSs. The one I still have is the one with 256Mb of memory. After trying for a while several different things, I concluded that RPi is a great piece of H/W but, (in spite of all the youtube videos) it's still not up to the job for Media Center.

Not sure how much difference doubling the RAM and software improvements have made since you last tried it, but this video seems to match my experience:
http://www.youtube.com/watch?v=v2Zh73CVIIk

the white screen/artifact when fast forwarding has been solved meanwhile, and my youtube addon experience is not nearly that bad (though its still slow and only barely usable).

Reply
#7
...
Reply
#8
(2013-01-17, 00:22)PobjoySpecial Wrote:
(2013-01-16, 23:33)MacUsers Wrote: ...but navigation is extremely slow.

This video matches my experience. Plenty fast, IMO.

Thats fairly impressive, also considering its a build from September. Noticeably smoother than my openelec on (admittedly, very slow) sdcard.
I was about to install openelec on a USB HDD to see if that made a big difference. Throughput would be higher no doubt, but Id expect latency to be worse, so I wasnt sure it would be a big gain. For sure I wouldnt have thought a USB stick would make a big improvement over an SDcard as the author of that video claims though?

Anyway, now I may have to try raspbmc too Wink.
And I took the liberty to link your video in the OP.



Reply
#9
...
Reply
#10
(2013-01-17, 01:00)PobjoySpecial Wrote: Take note that the GUI in that video is at 1080p, whereas OpenELEC renders at 720p and uses lower fanart resolution. It's not fluid, but good enough... IMO. Smile

I specifically sought out a card (SDSDU-008G-U46) known to have high 4K read/write speeds on the Pi. The Class rating doesn't really tell much about a card's real-world performance. It's best to look at benchmarks people have performed in Raspian. Flash drives seem to average higher 4K read/write speeds for some reason. Another option is NFS boot.

Thanks for that info. I see its $12 on amazon, so that wont break the bank, but Ill see what a USB hdd install does first, (assuming I get it to work). I have to copy all my media first, and copying 3TB over USB2 takes forever :p. Ill know more tomorrow.

On a totally unrelated side note; I just glued some ram heatsinks I had laying around on the Pi's CPU and videochip. Temps now dont exceed 50C in a closed case. Probably doesnt matter, but hey, I like to keep my chips cool Smile.


Reply
#11
(2013-01-16, 23:15)Vertigo Wrote: As I understand it, its not like there is a harware DTS decoder in there, but there are features of the audio chip that would enable on the fly DTS decoding without overtaxing the CPU,

Its done in software on the GPU so I guess hardware decoder is maybe the wrong term. GPU acceleration? Whatever, As you say, the key point is that it is done much more efficiently and takes a big load away from the struggling CPU in these scenarios. According to the devs who can use it, its working fine and fixes this issue of stuttery playback.


Reply
#12
If they use the GPU, rather than the audio chip (which might implement some patented or licensed technology from Dolby and/or DTS), then its even harder for me to understand how that would cause licensing issues that apparently dont exist when running the code on the CPU?
Not disputing what you are saying, Im just genuinely curious.
Reply
#13
It may not be the best idea to install to a usb hdd. A Usb3 flash drive works well. I know the PI doesn't support usb 3 but a 3 drive tends to be the fastest even on a usb2 port.
If I have been of help, please add to my reputation as a way of saying thanks, it's free.
Reply
#14
(2013-01-17, 01:41)Vertigo Wrote: If they use the GPU, rather than the audio chip (which might implement some patented or licensed technology from Dolby and/or DTS), then its even harder for me to understand how that would cause licensing issues that apparently dont exist when running the code on the CPU?
Not disputing what you are saying, Im just genuinely curious.

Software decoding on the CPU is done using open-source decoders.
Reply
#15
Nice writeup. I can't believe I am the first to rep you for it.
Reply

Logout Mark Read Team Forum Stats Members Help
Raspberry Pi for XBMC, some myths and truths 4