[FFmpeg-devel] [PATCH 2/2] CrystalHD: Add AVOption to control packed b-frame bug workaround.

[Philip Langdale]

On Sun, 24 Apr 2011 12:36:16 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> 
> the hardware isnt that wrong with behaving that way

I suppose not, but I'd prefer it to stick one behaviour or the
other :-)

> 
> also maybe you want to look at decode_user_data() and divx_packed
> maybe some of that could be used to detect the variants

I got one sample that didn't exhibit the bug, and then ran it through
MPEG4Modifier to unpack and repack it. The repacked version triggered
the bug. I've now done a binary diff and the headers are identical
except for a missing INFOISFT block (replaced with a JUNK block). I
think the important difference is in the delay frames. In the original
stream, the delay frame is written as:

30 30 64 63 08 00 00 00 00 00 01 B6 54 E2 13 7F

and in the re-packed stream it's:

30 30 64 63 07 00 00 00 00 00 01 B6 54 E2 13 00

From my little understanding of AVI, the '7F' in the first example is
what you want to see - and the second example is wrong, but I don't
know how wrong. ffmpeg with the normal software decoder doesn't exhibit
the same behaviour as the hardware for this kind of file, and the avi
demuxer is being used in both cases, so I don't believe it is the
problem.

--phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110424/7311c175/attachment.asc>