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

[Baptiste Coudurier]

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.
>>>
>> Patch attached for movenc.c
> 
> If I understand the problem correctly, maybe something like the attached
> (untested) patch could work (without useless copy).
> It changes ff_avc_parse_nal_units() so that it returns the actually written
> data size.
> 

It won't work for FLV because size needs to be written _before_.

This patch patch should work for mov assuming:

> [...]
>  
> +    if (enc->codec_id == CODEC_ID_H264 && trk->vosLen > 0 && *(uint8_t *)trk->vosData != 1) {
> +        /* from x264 or from bytestream h264 */
> +        /* nal reformating needed */
> +        size = ff_avc_parse_nal_units(pb, pkt->data, pkt->size);
> +    } else {
> +        put_buffer(pb, pkt->data, size);
> +    }
> +
>      trk->cluster[trk->entry].pos = url_ftell(pb);

"- size" is added here.

I will fix flv and mov.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no