[MPlayer-dev-eng] [PATCH] RFC: CrystalHD decoder support

[Philip Langdale]

 Hi all,

 For the past few weeks, I've been attempting to implement CrystalHD 
 decoder support,
 first directly in ffmpeg and then in mplayer - and I'll touch on why 
 that is in a moment.

 The current patch is largely functional with a few important 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 
 performs terribly for
 some reason.
 * Interlaced frames are not handled very well - it kinda works but 
 av-sync is a mess.
 * Files with resolutions above 720p probably won't play properly due to 
 not being able to
 get data in and out of the decoder fast enough. Broadcom state in the 
 driver/lib source that
 you need separate input and output threads to keep it fed and I'm not 
 sure how to reconcile
 that with the mplayer/ffmpeg API (I assume ffmpeg-mt could do this).

 However, the biggest issue is that the decoder breaks an assumption in 
 mplayer about how many
 calls to decode can occur before a frame is returned. At the start up, 
 the crystalhd might
 require 20 or more calls before it ever returns a frame, and without 
 increasing the maximum
 number of buffered_pts, it will start discarding them, ensuring that 
 av-sync goes out the window.

 So, I've bumped max buffered_pts to 128 in this patch - 64 was too low, 
 but it might need to be
 even higher for 1080p content. I'm also not sure how 
 QUERY_UNSEEN_FRAMES should be used. I don't
 know how many complete frames are in the decoder waiting to be decoded 
 and mplayer seems to be
 comparing the result with buffered_pts which comes from the pts passed 
 to each decode call,
 so I'm pretty confused. It also doesn't help with vd_ffmpeg adding 10 
 and then having it subtracted
 later. So I ended up returning 20 + the number of decode calls that 
 haven't returned a frame since
 the last flush. It seems to work but it's hardly scientific.

 With that in place, progressive <= 720p content plays well - with a 
 note that I have to force lavf
 to demux avi and wmv files correctly. The native demuxers dont' sync 
 properly - i think because
 they also make assumptions about how long you have to wait for frames 
 to come back.

 I'm not sure what's going on with interlacing. xbmc does line-doubling 
 on each field and the
 gstreamer plugin doesn't handle it at all so I had to guess, and while 
 I can construct a frame
 that de-interlacing filters are happy with, av-sync goes way out the 
 window; NTSC content plays
 at not-quite half rate (if I force 59.94, it plays slightly too fast), 
 etc.

 Now, why an mplayer plugin?

 I originally wrote this as an ffmpeg hwaccel on top of Gwenole's v2 
 patch with some additions to
 support accelerating decode_frame as opposed to decode_slice and it 
 kinda worked but most of my
 h.264 streams would make the crystalhd grumpy (those play fine with the 
 mplayer plugin). There's
 also no real benefit in terms of code sharing as the only place we need 
 codec awareness is the
 sps/pps decoding and ffmpeg's h.264 codec doesn't build up a compatible 
 struct anyway. I also
 had a problem where I just got solid grey output with x11/xv (but 
 correct frames with vdpau).

 So, combining all that with wanting to debug the sync problems as 
 directly as possible, I switched
 to an mplayer plugin and everything worked much better.

 Philosophically, I think it can be argued either way; you can consider 
 libcrystalhd to be a library
 codec like theora or xvid and say it's a valid mplayer codec on that 
 basis, or you can argue that
 it's an accelerator that should be usable from ffmpeg (although the 
 advantages for a transcode job
 are going to be very marginal).

 At this point, I'm not seriously suggesting it's ready to go in - the 
 interlaced handling needs to
 get sorted out and I think we need a more rigorous basis for how the av 
 sync interactions are done;
 still I'm sure some people will be very happy to see mplayer finally 
 using this hardware.

 --phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crystalhd.diff
Type: text/x-diff
Size: 28535 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20101219/212d86f7/attachment-0001.diff>