[Libav-user] Closing codec properly after an audio decoding
Polochon Street
polochonstreet at gmx.fr
Mon Aug 31 02:18:31 CEST 2015
Okay, so final mail (sorry!)
I finally solved my problem, after some hours of research: for audio
files with pictures embedded in tags, they were indeed detected and set
into the first frame, but it was not an audioStream (of course!) so I
had to add an « else » clause to my decode loop, like this:
while(av_read_frame(pFormatCtx, &avpkt) >= 0) {
if(avpkt.stream_index == audioStream)
(...)
else
av_free_packet(&avpkt); /* Dropping the damn album cover */
So, thanks very much for the help!
Le 30/08/2015 17:55, Polochon Street a écrit :
> Sorry for answering my own mail, but I've been finally able to obtain
> a full trace, thanks to --disable-stripping and some options of a
> PKGBUILD:
>
> ==3250== 4,793 (24 direct, 4,769 indirect) bytes in 1 blocks are
> definitely lost in loss record 235 of 237
> ==3250== at 0x4C2AED6: memalign (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==3250== by 0x4C2AFF1: posix_memalign (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==3250== by 0x554442F: av_malloc (mem.c:97)
> ==3250== by 0x55445FD: av_mallocz (mem.c:254)
> ==3250== by 0x5533DED: av_buffer_ref (buffer.c:94)
> ==3250== by 0x5281FF2: avformat_queue_attached_pictures (utils.c:395)
> ==3250== by 0x528C767: avformat_open_input (utils.c:486)
> ==3250== by 0x4021DD: audio_decode (decode.c:23)
> ==3250== by 0x4019F7: analyze (analyze.c:30)
> ==3250== by 0x401865: main (gui_dummy.c:24)
>
> It seems that I'm not freeing all of my AVFormatCtx streams properly,
> but I'm using avformat_close_input(&pFormatCtx) and
> avformat_free_context(pFormatCtx), am I missing something?
>
> Le 29/08/2015 20:40, Polochon Street a écrit :
>> Okay, so I compiled ffmpeg with those flags:
>> /configure \
>> --prefix=/usr \
>> --shlibdir=/usr/lib \
>> --disable-static \
>> --enable-debug=3 \
>> --disable-optimizations \
>> --disable-stripping \
>> --enable-gpl \
>> --enable-gnutls \
>> --enable-libass \
>> --enable-libfdk-aac \
>> --enable-libfreetype \
>> --enable-libmp3lame \
>> --enable-libopus \
>> --enable-libtheora \
>> --enable-libvorbis \
>> --enable-libvpx \
>> --enable-libx264 \
>> --enable-libx265 \
>> --enable-nonfree \
>> --enable-shared \
>> --enable-x11grab \
>> And I cmake'd my program with -DCMAKE_BUILD_TYPE=Debug
>> -DCMAKE_C_FLAGS=-fsanitize=address, but I still only have this debug
>> trace:
>>
>> ==17320==ERROR: LeakSanitizer: detected memory leaks
>>
>> Direct leak of 664 byte(s) in 2 object(s) allocated from:
>> #0 0x7f5aaf43e386 in __interceptor_posix_memalign
>> /build/gcc-multilib/src/gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:105
>> #1 0x7f5aaea93b0f in av_malloc (/usr/lib/libavutil.so.54+0x1db0f)
>>
>> Indirect leak of 4769 byte(s) in 2 object(s) allocated from:
>> #0 0x7f5aaf43e386 in __interceptor_posix_memalign
>> /build/gcc-multilib/src/gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:105
>> #1 0x7f5aaea93b0f in av_malloc (/usr/lib/libavutil.so.54+0x1db0f)
>>
>> SUMMARY: AddressSanitizer: 5433 byte(s) leaked in 4 allocation(s).
>>
>> The 29/08/2015 17:10, Carl Eugen Hoyos wrote:
>>> //First step (that is practically always sufficient)
>>> is to find out where exactly (!) the memory was
>>> allocated: We all know that it was inside mem.c
>>> but the important question is what called
>>> av_malloc().
>>> Either use a static binary or use
>>> --disable-stripping for a useful debug build.
>>>
>>> Carl Eugen
>>
>>
>>
>> _______________________________________________
>> Libav-user mailing list
>> Libav-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/libav-user
>
>
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20150831/9f325e67/attachment.html>
More information about the Libav-user
mailing list