[SOLVED] Broadcom BCM970015 mini-pcie crystal-hd card + VLC + YouTube

Question

Hi, since my notebook isn't powerful enough to play HD content I bought said card for about 42€ (the 970012 is much cheaper but doesn't support certain codecs) and installed it. Got it to work with VLC and YouTube pretty straightforward. For those who might be interested in the details, here's the story:
Cloned the git repo from git.linuxtv.org/jarod/crystalhd.git
and compiled the 'driver' and the 'linux_lib' and manually copied the firmware blob to /usr/lib.
modprobe'd crystalhd.
Noticed: Compiling gives an error until you add an
#include <linux/delay.h>
in crystalhd_flea_ddr.c. Wonder why they offer it buggy like that oO' but whatever.
Cloned the vlc 2.1.0 repo from git.videolan.org/vlc.git
-> bootstrap, configure --enable-crystalhd (I don't know if that parm is actually required, but what gives :-p), make, make install.
Noticed here though that 'make install' actually will NOT correctly install it. A 'vlc --version' still shows the old one (1.1.13). So, copied the binary and created symlinks manually in /usr/bin.
After this, invoking vlc with
vlc --codec crystalhd
will enable crystal-hd fine, as confirmed by the vlc command-line output you see.
If it doesn't, see the debug forum thread I linked at the very end of this thread.
NOTE: In 1080 I had smooth playback that was interrupted by "lags" every couple seconds. Turning up disk cache and file cache solved that for me. (Could also try turning down post-processing and loop filter, but maybe that isn't actually related?)
About YouTube: It works fine, even 1080p (previously I couldn't even watch 720p). Full-screen mode is still a little bit jerky, but it's not the usual low-frame prob but some other odd sort of mini lags, well that's the hell of flash I guess.
Although the latest flash (11.1.102.55-1) supports crystalhd out of the box it won't be enabled until you edit /etc/adobe/mms.cfg so that it has:
EnableLinuxHWVideoDecode=1
OverrideGPUValidation=true
At first I was missing the GPU-line and it didn't accelerate.
A final word - note that the crystalhd thingy only works single-threaded, basically if you have a YouTube video running, all other subsequently opened youtube videos or anything you play in VLC will NOT get hardware-acceleration because crystalhd is already occupied by the first video. So you cannot switch "on the fly" between videos, you have to close it first, then open another one!
Also, when I loaded a new video file in VLC without closing the player first, I got a kernel panic :-p I didn't test though if that actually happens everytime. But it seems the driver could still require further improvements...
Edit: I haven't attempted yet to compile ffmpeg with crystal-hd support, and I'm not sure if there are benefits over the pure VLC-solution. Let me know.
Last edited by Jindur (2012-03-01 14:18:17)

Answer 1

Jindur wrote:
Also, when I loaded a new video file in VLC without closing the player first, I got a kernel panic :-p I didn't test though if that actually happens everytime. But it seems the driver could still require further improvements...
Edit: I haven't attempted yet to compile ffmpeg with crystal-hd support, and I'm not sure if there are benefits over the pure VLC-solution. Let me know.
Just a quick reply for the caches: got similar issues with CrystalHD and VLC, and busy fixing it. Turns out that the driver (latest version) misses a NULL pointer in DriverGetStatus(). Additionally, VLC still does something quirky while opening the driver, which doesn't occur with e.g. the latest XBMC, resulting in a resource exhaustion leading up to that driver issue. For the first one, here is a small patch (the raw, 'uncut' version):
--- ../../../crystalhd/driver/linux/crystalhd_cmds.c 2012-03-18 15:59:58.743995349 +0100
+++ crystalhd_cmds.c 2012-03-26 18:21:18.398150371 +0200
@@ -745,7 +745,7 @@
bool readTxOnly = false;
unsigned long irqflags;
- if (!ctx || !idata) {
+ if (!ctx || !idata || !(ctx->hw_ctx)) {
dev_err(chddev(), "%s: Invalid Arg\n", __func__);
return BC_STS_INV_ARG;
@@ -828,6 +828,8 @@
static BC_STATUS bc_cproc_reset_stats(struct crystalhd_cmd *ctx,
crystalhd_ioctl_data *idata)
+ if (!(ctx->hw_ctx)) {
+ return BC_STS_INV_ARG; }
crystalhd_hw_stats(ctx->hw_ctx, NULL);
return BC_STS_SUCCESS;
This still will produce a multitude of errors in VLC, which remain largely unfixed ; one option to make VLC behave a bit more nicely when the above error occurs is to add this patch to VLC's crystalhd.c in DecodeBlock():
if (BC_FUNC_PSYS(DtsGetDriverStatus)( p_sys->bcm_handle, &driver_stat) != BC_STS_SUCCESS )
p_dec->b_error=true;
That's all for now, if I find more info I will share it here as this seems the only relevant thread on CrystalHD I found thus far
edit 2012-03-29: the issue is actually in the closing/releasing of the crystalhd driver by VLC. Somehow the VLC player only releases the driver *after* the new playout has changed, and it does not seem like a race-condition. The problem no longer appears when I simply ignore this usage in "chd_dec_close()" in "driver/linux/crystalhd_lnx.c" in the latest CrystalHD Linux driver (comment the if block
if(uc->in_use)
). This is a bad workaround, but it does the trick a bit better -> real fix is of course letting VLC handle the opening/closing of the driver better...
Last edited by sander4 (2012-03-29 15:44:03)