[FFmpeg-devel] Patch: CrystalHD decoder support

[Philip Langdale]

Hi all,

This is an update of my previously posted diff against mplayer
for a native mplayer codec implementation. I've ported it to work
directly against ffmpeg and improved its behaviour significantly
in the interim period.

The Broadcom CrystalHD chips are standalone video decoders that
decode video frames to system memory. As such, they are independent
of the GPU and usually appear as mini-card addons to laptops and
small form factor desktops. There are fully open-source drivers and
userspace libraries for Linux and OSX (and I guess windows too).

The main challenge when working with the hardware is keeping it happily
fed with frames - it is pipelined, so multiple frames are being
processed at the same time, and the lag between a frame being submitted
and the decoded frame being returned is significant - so the user
application needs to be capable of handling this characteristic. Under
normal conditions, there could be up to 20 frames in flight at once.
Empirically, I arrived at a 50ms delay between frame submissions during
the intial pipeline fill.

What works:

* Formats: mpeg1, mpeg2, mpeg4 part 2, mpeg4 part 10/h.264, vc1/wmv3.
* 'Typical' bitrates and codec features supported by hardware
* Progressive content
* Some interlaced formats. I've verified mpeg2 and h.264 mbaff.
* Screen resolutions up to 1080p

Caveats:

* It doesn't work properly with the 70012 hardware. I did all my 
 development against a 70015 and haven't really paid any attention
 to the 70012. It will run but it performed terribly in the past. I've
 been told that feeding frames in and pulling them out must be done at
 a very measured pace to keep it happy. It is likely better with the
 current patch but I've not tested yet.
* I'm not convinced it's flagging frames properly in some interlaced
  cases. I've got multiple dvb samples that don't make sense.
* Seeks behave strangely and the pipeline doesn't fill cleanly,
  resulting in much higher pipeline lengths than occur at the beginning
  of the stream. I've seen it go up to 50 frames in flight as a result.
* I still can only get avi/wmv containered content to sync correctly if
  I force lavf from mplayer, as opposed to native demuxers - even with
  -nocorrect-pts.
* Supposedly, the hardware can decode msmpeg4v3 but none of the samples
  I've found will play successfully.

Improvements over the initial patch:

* It's now against ffmpeg
* Pipeline length is now much more under control. mplayer doesn't need
  patching if you ignore the seek-related problem.
* Formatting and stylistic comments addressed
* Now some interlaced formats work as opposed to none of them.

I'm attaching both the main ffmpeg patch and the mplayer patch required
to use it from mplayer. The mplayer patch includes bumping the max
buffered_pts to 64.

Thanks,

--phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-crystalhd.diff
Type: text/x-patch
Size: 26285 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101227/5825110b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-crystalhd.diff
Type: text/x-patch
Size: 6250 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101227/5825110b/attachment-0001.bin>