[FFmpeg-devel] [PATCH] mpegtsenc: fix free of adts when not using AAC

Michael Niedermayer michaelni at gmx.at
Wed Oct 19 23:10:23 CEST 2011


On Wed, Oct 19, 2011 at 12:12:25AM -0500, Chris Kennedy wrote:
> On Tue, Oct 18, 2011 at 8:05 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> 
> > On Wed, Oct 12, 2011 at 09:59:44PM -0500, Chris Kennedy wrote:
> > > On Wed, Oct 12, 2011 at 10:18:22PM +0000, Carl Eugen Hoyos wrote:
> > > > Chris Kennedy <bitbytebit <at> gmail.com> writes:
> > > >
> > > > > There is a free for the adts data in writing the trailer onto mpegts
> > > > > files, yet it is only allocated when we are using AAC.  I have seen
> > > > > backtraces that point to this as the issue, although it oddly only
> > > > > segfaults on a very rare occasion.
> > > >
> > > > Please upload the sample that triggers the segfault for you.
> > >
> > > It's actually from a live stream from a clearQAM mpegts broadcast,
> > > so unfortunately has been impossible to get a file that triggers it.
> > > It's rare, once every week, and when it happens backtraces always
> > > point into libavformat somewhere from either the write trailer
> > > function or read frame function.  Here's the two backtraces I've
> > > gotten, always seems to be when closing an output context and opening
> > > a new one for mpegts.
> >
> > if you cannot upload a sample then maybe running the stuff under
> > valgrind might point more clearly to the cause
> >
> >
> This is what it does under valgrind:  This is the write frame one that
> happens, reading clearQAM HD signals over udp and from clearQAM cards.
>  There's also a av_read_frame issue too that seems to be either the mpegts
> parser doing something odd or somehow the input context streams changing.
>  Often times from what I can tell basically when the stream is very
> 'corrupted' then these cause the input context to get confused (thinking the
> audio codec or settings suddenly change, they don't, and new streams keep
> appearing).  Then output wise as below, it seems suddenly the packet buffer
> has some frames possibly that have a fully negative large stream index value
> and those cause a crash from trying to reference  a stream with them as the
> index.  So just seems like the whole internal system is being somewhat
> thrashed by the mpegts packets, admittedly from a probably bad input
> clearQAM signal.

I tried to fix the issue valgrind pointed too, please test and report
if the change fixed it or if theres some issue left

    [...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111019/462ccc25/attachment.asc>


More information about the ffmpeg-devel mailing list