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

[Aurelien Jacobs]

Baptiste Coudurier wrote:

> 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

Hum... Thanks !
Isn't it ironic that this sample was captured and uploaded by...
myslef ! (IIRC)
Anyway, the matroska muxer is now fixed and should handle such streams
correctly.

Aurel