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

[Philip Langdale]

On Tue, 8 Mar 2011 19:21:19 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:

> 
> why not just open the parser for the current codec and parse the
> frame?

So, I've been investigating this and the parser is partially useful.
It allows me to distinguish between MBAFF and PAFF content - which
is great, but it can't help me deal with these different PAFF cases
where the hardware returns a field-pair even when the input fields
are in separate packets. I end up in a situation where the packet's
picture_structure indicated it was a field, but when I match that up
with the output picture, the hardware really gave me a field pair
and the information is wrong.

Is there any justification in the standard for this behaviour or is
the hardware being weird and I have to look to the hardware for clues?

Right now, the only evidence I can find is in the next picture after
the ambiguous one. if the opaque 'timestamp' is the same as the first
picture, then we have two separate fields - if it's a different value,
then we're receiving field pairs. However, in the field pair case, I
now have two received field pairs to pass out, and while I think I can
do the juggling correctly, things are becoming ridiculous at this point.

The hardware does actually claim to publish the timestamp of the next
picture in the queue but it's usually not available because it hasn't
been decoded yet. *sigh*

--phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110313/7dfabcee/attachment.pgp>