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

[Baptiste Coudurier]

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:
./A-codecs/AAC/freetv_aac_latm.ts

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