Getting CrystalHD working with other Apps

[davilla]

Just thought I would post this and let everyone know. If you are
running into problems with getting the CrystalHD working (example,
app, etc) , it's perfectly acceptable with me to ask for help. This is
the only way I (we) will know if something needs improvement or
clarification. Don't suffer in silence, odds are I've already run into
any quirks under XBMC. I'm more than happy to help and this goes for
OSX as well as LInux.

[Gwenole Beauchesne]

Hi,

Le 12 févr. 10 à 19:19, davilla a écrit :

> Just thought I would post this and let everyone know. If you are
> running into problems with getting the CrystalHD working (example,
> app, etc) , it's perfectly acceptable with me to ask for help.

I finally got some time to play with it yesterday. So far, it worked
quite well. I have just uploaded hwdecode-demos 0.9.0 with Broadcom
Crystal HD support: <http://www.splitted-desktop.com/~gbeauchesne/hwdecode-demos/
>

It turned out to be rather simple. The complex part was my stupid MP4
parser because I didn't want to convert my sample clip to ES. ;-) The
next step is to play with DtsProcOutputNoCopy() and the callback
mechanism. And next, full video clips.

Regards,
Gwenole.

[Scott D. Davilla]

>I finally got some time to play with it yesterday. So far, it worked
>quite well. I have just uploaded hwdecode-demos 0.9.0 with Broadcom
>Crystal HD support:
><http://www.splitted-desktop.com/~gbeauchesne/hwdecode-demos/>
>
>It turned out to be rather simple. The complex part was my stupid
>MP4 parser because I didn't want to convert my sample clip to ES.
>;-) The next step is to play with DtsProcOutputNoCopy() and the
>callback mechanism. And next, full video clips.

Very nice Gwenole.

We use the DtsProcOutputNoCopy in XBMC to avoid the the extra
memcpy/convert step to yv12 and pass nv12 up to renderer. Helps on
CPU limited platforms to keep pushing around 1080p to a minimum. The
CrystalHD hw can also output two other packed yuv formats (which two
escapes me at the moment).

Scott

[Scott D. Davilla]

Since the two example video files referenced in the test app did not
make it into the initial release (size constraints), I've stuck them
into the downloads section.

See http://code.google.com/p/crystalhd-for-osx/downloads/list

test_video.264 is a JVT NAL sequence otherwise known as annex B
byte-stream format.

test.mpeg2 is straight mpeg2.

Both can be feed directly into the CrystalHD decoder without any
pre-processing.

Scott

[narensankar]

We can support NV12/YV12 and YUY2/UYVY in the HW in the BCM70012.

And in the BCM70015 we can currently support YUY2/UYVY in the HW. NV12
support coming soon ;-)

[davilla]

See http://code.google.com/p/crystalhd-for-osx/downloads/list

test.mpeg2 is straight mpeg2.

I've also updated the example code here so that it actually compiles.

Scott

[Gwenole Beauchesne]

Hi,

On Wed, 17 Feb 2010, narensankar wrote:

> We can support NV12/YV12 and YUY2/UYVY in the HW in the BCM70012.

According to the driver sources, YV12 support is not done in the HW. i.e.
NV12->YV12 conversion is pure C code. For now, it looks better to use the
*NoCopy() variant + do the CSC with libswscale.

Or I probably missed something, how can I retrieve decoded frames in YV12
from the HW?

Thanks,
Gwenole.

[Narendra Sankar]

That is correct. Sorry I was not clear.

YV12 is not exactly done directly in HW. YV12 is done by splitting the
NV12 buffers during the copy.

So you have to use NV12 or one of the 422 modes for the no copy.

> --
> To post to this group, send email to
> crystalhd-...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/crystalhd-development?hl=en
>