[FFmpeg-devel] [PATCH] CrystalHD decoder support v3

[Philip Langdale]

Hi all,

I figured it was time to post an update to the list.
This is still not ready to go in but we're getting much
closer.

Things that have improved since last time
-----------------------------------------

1) Introduced a mapping mechanism to avoid pts being mangled
by libcrystalhd. Right now I still feed it reordered_opaque
as the change to use pkt_pts isn't committed anywhere yet.

2) Packed b-frame DivX files now play correctly.

3) All forms of interlacing I've encountered are now handled
except that it's not possible to detect them. See below.

4) ffmpeg will now transcode correctly with crystalhd as the
source decoder. It remains a terrible idea because of the
unavoidable YUYV422 output format.

Things that remain outstanding
------------------------------

1) The LGPL 2.1 or later question is not formally resolved
yet but I've talked with the main broadcom engineer and he's
indicated that it won't be a problem - and I've sent him diffs
to make the change.

2) While I can handle all interlaced forms, I cannot detect them.
I can detect mpeg2 interlacing fine and I've seen three different
input/output field/fieldpair combinations on h.264 files but all
three look the same and I have to hack code to for each one. I've
reported this to broadcom but still waiting back on what I'm
supposed to do.

For the curious, I've seen:
a) One field per packet, one field per output call.
b) One field per packet, one fieldpair per output call.
c) One fieldpair per packet, one fieldpair per output call.

And mpeg2 is the final combination:
d) One fieldpair per packet, one field per output call.

3) ffplay works crappily as it struggles to cope with the decoder
lag. It takes about 20 seconds to reach sync. Michael previously
indicated that we need to add a formal lag concept and queue pts.
I've not had a chance to look at this yet.

4) 70012 support. It kinda works but the timing requirements for
the pipeline are different and I haven't worked out what they are
yet.

I have a git tree at https://github.com/philipl/ffmpeg-crystalhd
if anyone wants to track things on a day-to-day basis.

This patch should apply cleanly to either upstream.

--phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crystalhd-v3.diff
Type: text/x-patch
Size: 32401 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110130/56484a5e/attachment.bin>