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

[Chris Kennedy]

On Wed, Oct 19, 2011 at 4:10 PM, Michael Niedermayer <michaelni at gmx.at>wrote:

> 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:
> > > > >
> > > > 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
>

Thanks, I'm testing that out right now.  Oddly this was the 'write mux'
issue, not sure if the fix will also get the issue occurring in the 'read
mux'  or av_read_frame().  This of course is most likely from a corrupted
transport stream from clearQAM, so on the av_read_frame() I got this
backtrace and have basically saw that the frames have a size value but the
->data pointer points to an empty buffer (but still not NULL, just no data
and not the size of the ->size value).  So when GENPTS is set, and it goes
into the DUP_PACKET() function, it segfaults...

#0  0x00007ffff6c2c8eb in _int_malloc () from /lib64/libc.so.6
#1  0x00007ffff6c2d46b in _int_memalign () from /lib64/libc.so.6
#2  0x00007ffff6c2f521 in memalign () from /lib64/libc.so.6
#3  0x00007ffff6c30619 in posix_memalign () from /lib64/libc.so.6
#4  0x00000000009ac1fa in av_malloc (size=142484) at libavutil/mem.c:90
#5  0x0000000000532a4a in av_dup_packet (pkt=0x1417400) at
libavcodec/avpacket.c:130
#6  0x00000000004eb811 in av_read_frame (s=0x13bd040, pkt=0x7fffffffbd40) at
libavformat/utils.c:1339
#7  0x0000000000407eaf in main (argc=9, argv=0x7fffffffe588) at slicer.c:647


I need a valgrind output of this too I know, it just hasn't done this one
yet during valgrind sessions, but maybe these two issues are related.  I'm
basically just demuxing mpegts and remuxing the packets to mpegts again, I
have the corrupt packet dropping enabled and that has helped avoid all the
odd timestamps and bad values that would crash 0.7 and before much more
often.  Oddly it's only during network or card device reading, I've dumped
hours of streams with mplayer and re-ran them through and it never fails
then (and ffmpeg on these live streams can't even handle the timestamps, I
have had to use durations and avoid the actual timestamps else it wouldn't
remux).

Thanks,
Chris



>
>    [...]
> --
> 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"
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


-- 
---
Chris Kennedy