Jul 14 2010

New crystalhd support has landed

Category: Broadcom Crystal HD,Fedora,Linuxjarod @ 15:40

Well, it took a bit longer than I thought it would (and I suck at regular updates here), but the Broadcom Crystal HD bcm970015 cards are now working quite well under Linux. I swapped out the older 12 hardware for some 15 hardware in my thinkpad t61, and the driver now happily loads, library handles firmware uploads as appropriate for this hardware, gstreamer plugin builds, installs and even *works* using totem on fedora 13 with at least one h.264 sample clip I’ve got.

Broadcom ended up doing the bulk of the work (big thanks to Naren and his team at Broadcom), and have brought the driver and library pretty much up to full parity with their Windows driver. There’s been a lot of churn, and quite a bit of the new code (at least on the driver side) needs significant work to clean it up and make it look more like Linux kernel code before it can be sent along for upstream Linux kernel inclusion, but the important part for now is that its working.

Apr 01 2010

New Crystal HD device support Coming Soon (I swear)

Category: Broadcom Crystal HDjarod @ 01:01

Hrm, been a while since I’ve posted anything… Anyway, we’re busy working on support for the bcm970015-based Crystal HD decoder card now. At the moment, the git tree is a bit, um, unstable… The driver is at least working again on a bcm970012 part with some basic test code (hellobcm) if I use an older libcrystalhd, while the current libcrystalhd segfaults on me. We’ll get to the bottom of that soon… Kernel driver side support for the 15 is also getting there, but not quite ready yet.

Feb 10 2010

Crystal HD price drop and coupon

Category: Broadcom Crystal HD,Linuxjarod @ 15:56

Logic Supply once again has stock of the Broadcom Crystal HD cards, now down to $55.00, and with a $10 off coupon code, XBMC10. Get ‘em while they’re hot! (At least, I think the coupon code is still good…). I’ve been too busy to poke at mine for a few days, but I’ve got several of the newer bcm970015 part in hand now that I need to start working on support for in the crystalhd driver…

Jan 26 2010

Crystal HD vs. nVidia VDPAU decoding/playback

Category: Broadcom Crystal HD,Linuxjarod @ 13:49

I’ve been doing a fair amount of experimenting, mostly using xbmc’s svn trunk code, comparing the playback quality, cpu usage, codec support, etc. of both Broadcom Crystal HD-based decoding and nVidia VDPAU-based decoding of assorted video files I’ve got around the house. Now, open-source crystalhd support under Linux is quite new, as some of you may know. But the chip and driver have actually been around for quite some time, lurking in assorted set top boxes, if I understand correctly. The chip and driver, so far, seem pretty robust (not surprising, if they have indeed been in set top boxes for some time now), and definitely highly capable. nVidia’s graphics cards have been able to do video decoding for probably at least as long, but until a year ago or so, only the Windows drivers supported that functionality, so VDPAU is relatively new as well, but its usage is a bit more established than the crystalhd in the world of open-source. (Note, of course, that while there’s an open-source libvdpau, the only way to provide a working decoder backend for libvdpau is via binary-only drivers from nVidia or S3, the latter of which I know nothing about, so for the open-source purists, crystalhd is a win here).

The question many people have asked me (on mythtv irc and mailing lists, primarily), is ‘how does it compare to VDPAU?’. Well, it compares quite favorably. I’ve got a development box with an nVidia Quadro FX 1700 and a Broadcom Crystal HD card in it that I’ve been poking at the past few nights. For fully-compliant h.264 streams, there’s little or no difference in the quality of the decoders, with maybe a *slight* (and possibly only perceived and subjective) edge to the Crystal HD decoder. They’re both quite good. Like, you can’t tell this is a desktop computer playing back the video and not a commercial blu-ray player good. At the moment, less-than-100%-spec-compliant h.264 clips tend to give the Crystal HD fits, while they play fine using VDPAU. However, most of that is software-side, and can/will be remedied as development progresses.

As for mpeg2 (aka High-Definition TV in the US), the Crystal HD does support that as well, but most work has been focused on h.264 to date. The mpeg2 decoding via Crystal HD in xbmc isn’t quite there yet, but Scott has been working on it. A few days ago, 1080i mpeg2 content had a nasty green cast to it, along with alternating light and dark stripes. The green cast is gone now, but the stripes persist — it also looks like either fields are playing out of order or being drawn in not quite the right locations, visually manifesting as the picture oscillating up and down a pixel or two. Both 720p and 1080i lose sync after a bit as well, and then the player thrashes about trying to get them back in sync (or something). But they’re known issues, and progress is being made.

I have to add this data point though: while playing back some 1080p h.264 video decoded by the Crystal HD this past weekend, my wife said “wow, that looks so good! why does it look so good? I don’t remember it looking that good before!” (more or less). :)

So why should you choose one over the other? Depends on a few things… If you’re in the camp that is morally opposed to binary-only software, such as the nVidia graphics driver, the Crystal HD route is far less morally reprehensible. It *does* require use of a binary-only firmware image that must be loaded onto the card, but otherwise, the driver and interface library are 100% open-source (GPL driver, LGPL library). The driver is in the Linux kernel staging tree, and the library is making its way into Linux distributions. The Crystal HD isn’t dependent on any particular graphics chipset either. I’ve got an Intel X3100 graphics Lenovo ThinkPad T61 and an Intel GMA950 Mac Mini, neither of which I could replace the graphics chipset in. Both have mini PCIe slots though. And now both can play back 1080p h.264 using the Crystal HD, whereas before, notsomuch. Note however, that there are higher cpu and memory requirements for using the Crystal HD to decode video than for VDPAU. This is the down side of it not being tied to a particular graphics chipset. Because its a separate device, there is occasional format conversion (rgb to yuv, nv12 to yv12, etc., etc) and buffer copying (from Crystal HD to graphics card) that has to be done, rather than everything occurring strictly within the graphics chip. That said, even a lowly 1GHz AppleTV with 256MB of RAM can play back 1080p h.264 with a Crystal HD (its just pretty close to maxed out). Chances of having a PCI express-capable chipset with a CPU slower than that are minimal. Single-core Atom systems, particularly in netbooks, are one of the main targets for the Crystal HD.

Back to the hardware for a moment… To make room for the Crystal HD in my T61, I yanked the worthless-under-Linux Intel TurboMemory card. In the Mac Mini, I yanked the wifi card, since I have wired GbE to it. If you have a system with an available PCIe slot, its probably easier to simply drop an nVidia graphics card in — partially because the Crystal HD is only generally available in a mini PCIe card format right now, meaning you’d need an adapter to use one in a PCI express system w/o a mini PCIe socket (but these do exist). Remember the above-mentioned development system w/the Quadro FX 1700 in it? Its actually a tower with no mini PCIe socket — I have a PCIe x1 Crystal HD card courtesy of Broadcom, its just not available anywhere on the open market at this time. They’d like for it to be, as well as an expresscard variant (for laptops without an available internal mini PCIe socket to spare), but the mini PCIe is likely to be the one most in demand by far, so only time (and market conditions) will tell what options become available.

Jan 22 2010

Crystal HD and xbmc

Category: Broadcom Crystal HD,Fedora,Linuxjarod @ 02:37

They work fantastically well together. Scott Davilla, who is the one that got the ball rolling on open-sourcing the crystalhd driver and library and brought me into the fold, has done an outstanding job with the xbmc development trunk code, adding support for offloading decoding to the crystalhd. I grabbed the Big Buck Bunny 1080p h.264 clip and threw it at a build of today’s xbmc on an x86_64 Fedora 12 install on my Lenovo ThinkPad T61 (sporting a Core 2 Duo processor at 2.2GHz and Intel X3100 graphics), and the system hardly broke a sweat, topping out at 39% cpu usage, with absolutely flawless decoding and perfectly smooth playback. Juxtapose this with mplayer operating on the same file, pegging one cpu core, with obvious dropped frames, stuttering, etc. Good stuff.

Jan 21 2010

Crystal HD xine plugin

Category: Broadcom Crystal HD,Fedora,Linuxjarod @ 12:04

Managed to hack together a xine-lib-1.2 hg development tip rpm for Fedora 12 last night. After getting that installed on my ThinkPad T61, the xine crystalhd decoder plugin built without a problem. Installed it, and let xine have at it with an h.264 clip from my Hauppauge HD PVR. Lo and behold, it works! Not exactly perfect just yet — there was a xine process spinning at 120% in top during playback and the video didn’t quite look smooth — but it did play back the video, decoded by the crystalhd. More poking later. Need to take a closer look at xbmc’s crystalhd support too.

Jan 14 2010

The Broadcom Crystal HD and Linux story thus far…

Category: Broadcom Crystal HD,Fedora,Linux,Mac OS X,MythTV,Red Hatjarod @ 00:41

So at least six months ago now, I was first contacted by Scott Davilla of XBMC and AppleTV fame, whom I’ve had misc conversations with a number of times previously, (mostly about running MythTV on the AppleTV under Linux), about a very cool new toy he was playing with that would allow the AppleTV to play back 1080p h.264 material nice-n-smooth. Well, really not all that new a device, just new in the sense that there was actual traction on an open-source driver for it seeing the light of day. That device was the Broadcom Crystal HD decoder card, aka the BCM970012.

Now, the Crystal HD has been available as an OEM add-on for a number of systems with Windows drivers for a few years now, and prior to that, I think earlier incarnations existed in various set top boxes (which possibly were running some form of embedded Linux…). Dell has been shipping the decoder card for a while as the “Broadcom BD Accelerator card”. That would be BD and in “Blu-Ray Disc”. However, don’t get too excited about the prospect of a Linux Blu-Ray Disc playback solution just yet. More on that later… HP has been bundling the same card with their Mini 110 systems. Not too long ago, one of my favorite smaller online shops (juxtaposed to newegg or amazon), Logic Supply, which carries lots of hard-to-find-anywhere-else mini-itx and assorted embedded stuff, started selling the card as well.

Anyhow, Scott had put out some feelers about the Crystal HD, and managed to make contact with someone in Broadcom’s MediaPC division, who was in fact looking for community folks to help with Linux driver support. Amusingly, not long after I’d first talked to Scott about this, I talked to a guy I play pickup soccer with, who also happens to work for Broadcom, and he said he’d dig around and see if he could get me the name of someone to talk to about the Crystal HD as well. The name he turned up was the very same individual Scott had been talking to. Now, as you may or may not know, I happen to work for Red Hat, in its kernel group. I’m far from an elite kernel hacker myself, I’m just a trainee, if you ask me, but I work with some absolutely brilliant kernel people. This is attractive to someone like Broadcom looking for help with their kernel driver. :) Needless to say, the ball started rolling rather quickly at that point, and Broadcom’s Naren Sankar gave the thumbs up for Scott to pass along a copy of the full kernel driver and userspace library source for me to start poking at.

The code was… Well, typical of a lot of vendor code. For the most part, I cared first and foremost about the kernel driver. Lots of wrapper functions, rather than using kernel functions directly, Windows ifdeffery, and so on. But generally, pretty well laid out and thorough code, with reasonably good documentation in headers about what functions did, what register contents meant, etc. Okay, so on to compiling… Or not. My main development systems are pretty much all 64-bit Fedora, with fairly up-to-date kernels. Double-fail on that one. I can’t remember the exact details anymore, but it pretty much only worked on an older 32-bit kernel — Red Hat Enterprise Linux 5′s 2.6.18 kernel worked, as did Ubuntu 8.04′s kernel. If you’re gonna get the thing upstream, its kinda gotta work on the latest kernel, and be portable to 64-bit. So that was the focus of my late-night efforts for the next few weeks. Getting it to build on newer kernels wasn’t too much work. Making it build on 64-bit kernels was a lot more work. Then getting it to actually *work* on a modern 64-bit kernel was even more work. But now it does. :)

There was a bunch of additional code reformatting involved as well, so the driver looked more like Linux kernel code, then some assorted sanitization (libcrystalhd was originally called libldil — ldil being ‘linux driver interface library’ or something like that, and the crystalhd kernel module was originally called mpclink, iirc), new license headers, etc., a few more rewrites here and there to satisfy Broadcom legal, and finally, on December 29, 2009, a public release of the Linux kernel driver under the GPL, the Linux userspace library under the LGPL. From there, a bit more clean-up (being tracked in a git tree, of course), a submission of the driver to the Linux Kernel Mailing List by someone other than those of us who’d been working on it for the past 6 months (Manu Abraham graciously stepped aside when he found out we’d been working on it and planned to submit it), and then we finally got something off to lkml. On January 6, 2010, the driver was merged into the Linux kernel staging tree. Woo!

I’ve also patched the driver into the latest Fedora 12 and rawhide (F13-to-be) kernel trees, and submitted the userspace library as a new package for Fedora. Note that the firmware doesn’t yet have a license upon it that permits redistribution (redistributable, no modification, a la many other kernel driver firmware files), but Naren was working with Broadcom legal to make that happen. Note that the git tree I’m hosting builds on kernels going back at least as far as 2.6.18 (2.6.11, I think, but I’ve only tried back to 2.6.18 myself), and there’s source for a gstreamer plugin included in the tree. If you look at the Fedora package review bug, you’ll note that it doesn’t work so hot with current gstreamer, but it does work on older versions, and I’m hoping to get some help from one of Red Hat’s gstreamer gurus to fix it up to work with more current bits…

Speaking of firmware and getting back to that Blu-Ray Disc playback issue… The firmware for Linux does NOT include support for Blu-Ray Disc decoding. There are all sorts of “trusted path” requirements that would be… trick… to meet with an open-source driver. :( The driver doesn’t have code to support BD even if you did try loading firmware from a Windows driver that purported to support BD playback. Oh well.

Now, what we *can* support, is playback of MPEG2, h.264 and VC1 files. Without violating any (admittedly STUPID) codec patents here in the US or having to purchase a license. The decoding is all done in hardware. With almost no cpu usage. (Almost, because we do have to dma the encoded bitstream into the decoder, then dma out very large buffers full of raw video frames, and transplant that over to your gpu, but an AppleTV with its 1GHz proc can handle 1080p h.264 with this thing, so can a single-core Atom N270).

Scott has been hard at work adding Crystal HD support to XBMC and a port of the driver and library to Mac OS X, and has made excellent progress. Edward ‘gimli’ Hucek has been working on a xine plugin. Word has it a few ffmpeg developers have starting poking at support there too — which is the part I’m personally most interested in, as MythTV can inherit that work. (I actually started poking at MythTV code myself, seeing what needed to be added where to support the Crystal HD, but I’ve not had time to get up to speed on the code, nor will I likely anytime soon, and quite frankly, its probably better if the ffmpeg guys do the work, I’m really nowhere near as comfortable working outside the kernel… :) .

Oh, there’s also a very crude smoke-test app in examples/ in the crystalhd source tree. Its hard-coded to a specific video type in a specific file path, but its useful for sanity-checking if the decoder is working. It doesn’t display anything, it just takes in a clip, decodes frames, and spits back a bit of data about them, discarding the actual decoded video frame. More of just a developer usage thing, good for headless setups where ssh’d into a machine and the like. Ping me and/or Scott if you want to poke at it and need help making it behave, but most of the gory details can be seen in the post and comments over here in the Breaking Eggs And Making Omelettes blog, which if I understand correctly, belongs to one of the ffmpeg developers…

So yeah, that’s about where things are at right now… Stay tuned for updates, I’ll try to keep on top of them here…