[Libav-user] Possible memory leak with avcodec_decode_video2

[David Tsulaia]

On Mon, Dec 28, 2015 at 3:26 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> David Tsulaia <d_tsulaia at ...> writes:
>
> > ffmpeg version N-75912-g624057d Copyright (c) 2000-2015
>
> Please test current FFmpeg git head before reporting
> issues.
>
> > No matter what I try call to avcodec_decode_video2
> > results in memory leak.
>
> valgrind output missing.
>
> Carl Eugen
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>


I feel ashamed for coming to mailing list so unprepared.
Must have been several nights no sleep and desperation.

Now, I used current git build and showed similar results,
but I researched more and found out what was the issue:
It wasn't memory leak that's why valgrind constantly showed
that all heaps were freed and no leaks were possible.
The problem was that av_decode_video2 and av_interleaved_write_frame
both buffer packets for processing/reordering. Thing is the stream is so
large
that both of these calls were not fast enough to deal with incoming packets
so memory usage kept climbing up.
I fixed this by using av_write_frame and provided already interleaved
stream.

So my bad for not noticing that.

I have another issue I would like to get some help if possible:

Could you please tell me how to correctly switch between files while
reading stream.
I am recording 1 hour long files from constant stream. Right now I am doing
following:

avio_open2(&ofmt_ctx->pb, fname, AVIO_FLAG_WRITE, NULL, NULL );
after 1 hour.
avio_close(ofmt_ctx->pb);
make new file name
avio_open2(&ofmt_ctx->pb, new_fname, AVIO_FLAG_WRITE, NULL, NULL );

Is this right? I though of freeing context and reallocating it again,
but wanted to avoid extra tasks in reading/writing loop.

P.S. Happy holidays everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20160111/2809e70a/attachment.html>