[FFmpeg-devel] [PATCH 2/2] CrystalHD: Add AVOption to control packed b-frame bug workaround.
philipl at overt.org
Sun Apr 24 19:46:48 CEST 2011
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the ffmpeg-devel