[FFmpeg-devel] [FFmpeg-cvslog] r16616 - in trunk/libavformat: avc.c avc.h flvenc.c matroskaenc.c movenc.c

Baptiste Coudurier baptiste.coudurier
Mon Jan 19 22:52:41 CET 2009

Hi Aurel,

Aurelien Jacobs wrote:
> Baptiste Coudurier wrote:
>> Baptiste Coudurier wrote:
>>> Aurelien Jacobs wrote:
>>>> Baptiste Coudurier wrote:
>>>>> Hi guys,
>>>>> lucabe wrote:
>>>>>> Author: lucabe
>>>>>> Date: Thu Jan 15 15:03:07 2009
>>>>>> New Revision: 16616
>>>>>> Log:
>>>>>> Do not reallocate AVPacket's data when muxing a packet
>>>>> Argh, I just noticed a problem with the patch, this broke muxing if nal
>>>>>  startcodes are not 4 bytes :(
>>>>> I think this must be reverted and the other approach must be used
>>>>> (allocating a new buffer).
>>>>> I will implement this in flv and mov muxer, I don't know much about mkv
>>>>> muxer.
>>>> For now, I haven't checked the problem you are talking about, but if
>>>> you send a patch with a different implementation for mov and flv, I
>>>> will happily adapt it to mkv.
>>> Basically, when bistream uses 3 bytes nal startcodes, output size will
>>> differ from input size, and this is not considered (old size is written
>>> in the packet header), so output size must be computed before actually
>>> writing data in the packet.
> BTW: do you have a h264 sample with such a 3 bytes nal startcodes ?
> For now, the matroska muxer uses the following code to detect whether
> it should do nal reformating or not:
>   AV_RB32(codec->extradata) == 0x00000001
> So I guess it simply won't detect the kind of bitstream you are talking
> about. I would like to fix this, and a sample would help.

Sure, IIRC:

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org

More information about the ffmpeg-devel mailing list