[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] broadcom crystal hd support

From: Jacob Beard
Subject: Re: [Gnash-dev] broadcom crystal hd support
Date: Sun, 7 Nov 2010 13:51:41 +0100


I've had some time to try out the Crystal HD stack from Broadcom on
Ubuntu Lucid, and the gstreamer plugin does appear to work, although
hasn't been the most stable (I was able to cause a kernel panic last
night somehow, maybe by trying to seek inside a video stream, which
the README says isn't currently supported). The drive provides nice
output via dmesg to state when the hardware is in use ("opened") by an
application, and when it is closed.

Knowing very little about how Gnash uses gstreamer, my hope is that it
might "just work" and use the crystal gstreamer plugin. Because of the
dmesg logging, it should be easy to test this: I think I should just
need to use Gnash to play an mpeg4 video, and check whether the
Crystal HD hardware has been opened in dmesg.

Unfortunately, I'm having troubling determining what is the easiest
way to play an mpeg4 video with Gnash. This is simply a problem of
website compatibility, as the video sites I've tried (youtube and
vimeo) don't appear to work on Gnash 0.8.7 on Ubuntu Lucid. I'm not
concerned with attempting to solve this compatibility issue now.
Rather, I'd simply like to know: what the easiest way is to play a
video with Gnash? Perhaps I should use the standalone player, or maybe
there is a particular video hosting site which is known to be highly
compatible with Gnash.

Let me know what you think. Thanks,


On Sat, Nov 6, 2010 at 9:35 PM, Jacob Beard <address@hidden> wrote:
> It's also probably worth mentioning that Adobe Flash currently
> supports the Crystal HD API, I think since 10.1, but only on Windows.
> If Gnash could pull ahead in terms of hardware acceleration support on
> Linux, I think that would have significant value.
> Best,
> Jake
> On Sat, Nov 6, 2010 at 9:31 PM, Jacob Beard <address@hidden> wrote:
>> Hi,
>> Thanks for the reply.
>> On Sat, Nov 6, 2010 at 6:31 PM, Rob Savoye <address@hidden> wrote:
>>> On Sat, Nov 06, 2010 at 12:17:09PM +0100, Jacob Beard wrote:
>>>> video content for the Broadcom Crystal HD chipset. You're starting to
>>>> see this chip show up in a lot of netbooks. Broadcom has released open
>>>> source drivers, an application library, and a gstreamer plugin, most
>>>> of which seem to have made it into Ubuntu Maverick.
>>>  Interesting... I hadn't heard of that one. If it's in Maverick, I can try
>>> it.
>> I'm still just figuring all of this out myself (having only recently
>> bought the hardware), but it seems the firmware is in
>> linux-firmware-nonfree
>> [],
>> and the kernel module is crystalhd.ko in the generic kernel
>> [].
>> I'm not sure whether the application library and gstreamer plugin are
>> in apt, but the LGPL sources are available on the broadcom site,
>> explicitly mention Ubuntu in the README, and were no trouble to build
>> and install on Ubuntu Lucid:
>> I'm still testing it to see how well it actually works.
>>>> I know Gnash now supports VAAPI, and it also seems as though someone
>>>> is working on a backend for the crystal API for VAAPI, which but it
>>>> seems not be very mature:
>>>  You mean vaapi or the crystal API isn't mature ?
>> I mean the Crystal HD backend of the VAAPI isn't mature. See:
>> It seems quite young.
>>>> It would therefore be interesting if Gnash could make use of the
>>>> crystal API in some other way, perhaps via Gstreamer and the crystal
>>>> plugin.
>>>  It probably can. Right now I'm slowly (between other tasks) refactoring
>>> the rendering API in Gnash to better support things like HW accelerated 
>>> video.
>>> While the current VAAPI support works, I think how it works can be improved.
>>> I'll look at the docs, but if this is a gstreamer plugin (OMAP is the same),
>>> there may not be anything Gnash has to do special to utilize this.
>> That's great to hear.
>>>  I'd have to find some hardware with this chipset to really know if it 
>>> works.
>> I'd be happy to test any builds.
>> Thanks,
>> Jake

reply via email to

[Prev in Thread] Current Thread [Next in Thread]