On Wed, 8 Jun 2011, Etienne Buira wrote:
> On Wed, Jun 08, 2011 at 10:55:03PM +0300, Martin Storsjö wrote:
> > The original commit that this is a cherry-pick of actually
> > introduced a memory leak - this only fixes the potential
>
> What leak? If I trust libavformat/utils.c:avformat_free_context(),
> av_opt_free() is called so the hunk you removed is only a small cleanup.
If that were the case, it'd be a case of mixing two different things in
the same commit - in the original form, it looked like it was related to
the change of av_free to av_freep, which it was clearly not.
> You're welcome to state if I'm wrong.
In the applehttp demuxer (which is the only place where the crypto
protocol is used today, and it's not usable standalone at the moment,
since you can't pass avoptions to protocols from the command line), the
input is closed manually via a plain ffurl_close (since it uses a custom
AVIOContext), where av_opt_free never is called on it. Also, even if it
was closed as a normal AVIOContext, we only call av_opt_free on the
AVFormatContext and its private data, not on the URLContext's private
data.
To see it in action, try valgrinding "ffmpeg -i
'http://albin.abo.fi/~mstorsjo/applehttp-crypt/prog_index.m3u8";.
This cleanup could perhaps be done if we'd make ffurl_close call
av_opt_free on the private data, though - that might make sense.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
