[MPlayer-dev-eng] [PATCH] RFC: CrystalHD decoder support
mplayer.philipl at overt.org
Mon Dec 20 02:50:04 CET 2010
For the past few weeks, I've been attempting to implement CrystalHD
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
* 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),
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 28535 bytes
Desc: not available
More information about the MPlayer-dev-eng