[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