> On 2 Jan 2019, at 18:05, Nicolas George <geo...@nsup.org> wrote: > > Oliver Collyer (2019-01-02): >> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c > > Please use git format-patch to prepare your patches. Also please try to > convince your MUA to use text/plain for patches. > >> +static int open_enc_count = 0; >> +static pthread_mutex_t open_enc_count_lock = PTHREAD_MUTEX_INITIALIZER; > > Static variables are unacceptable. And indeed, these are wrong: you are > counting several instances, possibly of different APIs, but with a > single counter. >
Yes, I see what you mean. > The way I read things, the leak you are trying to fix does not exist: it > is global state, kept until the end but not lost. > Well, as per my earlier post - x265 provides a function to free up this memory which otherwise isn't freed up, hence memory debuggers report these allocations as leaks, and ffmpeg provides no mechanism to call this function. I guess the OS frees it up on application exit, but that seems a messy way to be going about things, I guess that's why the developers of x265 provided the function. > Regards, > > -- > Nicolas George > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
