[FFmpeg-devel] [PATCH] libavformat/avc.c annexbparsing corrupts packets

[Jason Garrett-Glaser]

On Sun, Feb 21, 2010 at 4:35 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Mon, Feb 22, 2010 at 01:06:13AM +0100, Michael Niedermayer wrote:
>> On Wed, Jul 29, 2009 at 01:15:12PM +0200, matteo elli wrote:
>> > > code in libavformat/avc.c is seldom executed but it surely does when you
>> > transmux (vcodec=copy) from h264 in a ts container to h264 in an
>> > mp4/mov/mkv/avi container.
>> > >
>> > > The code there fails to handle annexb 00 00 01 NAL three byets prefixes
>> > properly and cuts the last byte in the previous NAL corrupting the whole
>> > frame.
>> >
>> > please provide a reproduceable testcase
>> >
>> > ...
>> >
>> > ok I have arranged a little testcase, see these files:
>> >
>> > http://www.m-elli.com/annexb-test.ts
>> >
>> > the original ts file
>> >
>> > http://www.m-elli.com/annexb-test-ffmpeg-0.5.mp4
>> >
>> > the original ts file processed by ffmpeg-0.5 without patch (command "ffmpeg
>> > -i annexb-test.ts -vcodec copy -an -f mp4 annexb-test-ffmpeg-0.5.mp4")
>> >
>> > http://www.m-elli.com/annexb-test-ffmpeg-0.5-patched.mp4
>> >
>> > the original ts file processed by ffmpeg-0.5 with patch (command "ffmpeg -i
>> > annexb-test.ts -vcodec copy -an -f mp4 annexb-test-ffmpeg-0.5-patched.mp4")
>> >
>> > http://www.m-elli.com/annexb-test-nal-tree.txt
>> >
>> > the NAL tree generated with H264Visa from the original ts file, I have
>> > commented the first pict comparing lengths to the annexb-test-ffmpeg-0.5.mp4
>> > file like this:
>> >
>> > + NAL(Pic No. in decoding order)
>> > ? ? + Before First Picture
>> > ? ? ? ? + NAL Type: AUD, Len: 2, Pos: 10(0xa)
>> > ? ? + Pic 1(Dec Order)
>> > ? ? ? ? + NAL Type: SPS, Len: 25, Pos: 19(0x13)
>> > ? ? ? ? + NAL Type: PPS, Len: 4, Pos: 48(0x30)
>> > ? ? ? ? + NAL Type: SEI, Len: 11, Pos: 56(0x38) ? -> becomes len 12 (0x0c)
>> > ? ? ? ? + NAL Type: IDR, Len: 35837, Pos: 71(0x47) ?-> becomes len 35836
>> > (0x8bfc) -> one byte truncated !!!
>> > ? ? ? ? + NAL Type: IDR, Len: 37451, Pos: 35912(0x8c48) ?-> becomes len
>> > 37452 (0x924C)
>> > ? ? ? ? + NAL Type: IDR, Len: 38904, Pos: 73371(0x11e9b) -> becomes len
>> > 38908 (0x97fc)
>> > ? ? ? ? + NAL Type: IDR, Len: 39717, Pos: 112279(0x1b697) -> becomes len
>> > 39716 (0x9b24) -> one byte truncated !!!
>> > ? ? ? ? + NAL Type: IDR, Len: 61112, Pos: 152003(0x251c3) -> becomes len
>> > 61116 (0xeebc)
>> > ? ? ? ? + NAL Type: IDR, Len: 31483, Pos: 213125(0x34085) -> becomes len
>> > 31489 (0x7b01)
>> >
>> > as you can see NAL lengths are wrong, this is usually not an issue when len
>> > is greater but in slices 1 and 4 one byte is missing and the whole pict gets
>> > corrupted
>>
>> no corruption is reproduceable
>> there may be bugs but this is not a useable bugreport
>
> ive fixed what was obviosuly wrong, i dont know if this fixed your
> issue or not

I've modified x264 locally to implement short startcodes for slices
other than the first (for multislice encoding).  It saves a few bytes,
and I can confirm that it did not work before your fix (with ffmpeg -i
input.h264 -vcodec copy output.mp4), and it works now.

Dark Shikari