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

[Philip Langdale]

On Sun, 24 Apr 2011 10:16:16 -0700
Philip Langdale <philipl at overt.org> wrote:

> 
> 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.

After more reading:

So the second frame is a 'drop frame', I take it. I guess that's a valid
alternative to a delay frame?

Anyway, can I look at the packet size (8 vs 7) to distinguish the two
cases?

--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/9aca16a2/attachment.asc>