[Ffmpeg-devel] -vcodec copy h264 from mp4 to avi weirdness

[Måns Rullgård]

Loren Merritt <lorenm at u.washington.edu> writes:

> On Sun, 18 Jun 2006, M?ns Rullg?rd wrote:
>
>> Something strange happens when copying h264 video from mp4 format to
>> avi.  The output file simply will not decode with ffmpeg if lavf is
>> used for demuxing.  Instead, lots of errors are printed:
>>
>> [h264 @ 0xb7ecf188]top block unavailable for requested intra mode at 4 0
>> [h264 @ 0xb7ecf188]error while decoding MB 4 0, bytestream (3093)
>> [h264 @ 0xb7ecf188]top block unavailable for requested intra mode at 33 5
>> [h264 @ 0xb7ecf188]error while decoding MB 33 5, bytestream (12960)
>> [h264 @ 0xb7ecf188]top block unavailable for requested intra4x4 mode -1 at 20 5
>> [h264 @ 0xb7ecf188]error while decoding MB 20 5, bytestream (3311)
>> [h264 @ 0xb7ecf188]top block unavailable for requested intra mode at 32 5
>> [h264 @ 0xb7ecf188]error while decoding MB 32 5, bytestream (1717)
>> ... lots more of the same stuff...
>>
>> TCVP and xine both play the file properly with their native avi
>> demuxers.  TCVP with lavf fails.
>>
>> This happens with every sample I've tried.  NeroAVC.mp4 in the mplayer
>> samples collection is one of them.  Copying the video to a new mp4
>> file works fine.
>>
>> Does anyone have an idea what could be causing this?
>
> Because h264 is one of those brain-damaged formats that has different
> encodings depending on which container it's in?

It's not all that bad IMHO.  There are two well-defined ways of
storing the data, and a container format can choose whichever is more
suitable.  If the container separates frames there is no need to waste
bytes in the elementary stream for the same purpose.

> MP4 and MKV use the AVC1 encoding (length-prefix), AVI, ES, and TS use
> the Annex B encoding (startcodes).

That doesn't explain how other demuxers get it right.  The TCVP
demuxer does nothing special at all.  It simply treats any extra bytes
in the stream header as codec specific data which eventually ends up
in AVCodecContext.extradata.  I'm failing to see how the data that
gets to the decoder is different with the different demuxers, but
there's got to be something.

-- 
M?ns Rullg?rd
mru at inprovide.com