Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Oliver Collyer
> On 2 Jan 2019, at 19:18, Steinar H. Gunderson > wrote: > > On Wed, Jan 02, 2019 at 04:34:28PM +0100, Nicolas George wrote: >> This is not a leak, it is short-sightedness by leak detectors. > > Most modern leak detectors distinguish between memory that's still reachable > (usually not a leak)

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Steinar H. Gunderson
On Wed, Jan 02, 2019 at 04:34:28PM +0100, Nicolas George wrote: > This is not a leak, it is short-sightedness by leak detectors. Most modern leak detectors distinguish between memory that's still reachable (usually not a leak) and memory that's not (almost always a leak). This sounds like an examp

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Oliver Collyer
> On 2 Jan 2019, at 18:38, Nicolas George wrote: > > Oliver Collyer (2019-01-02): >> Can you clarify what you mean by "static variables are unacceptable". >> They're all over the place in ffmpeg (random example >> https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Hendrik Leppkes
On Wed, Jan 2, 2019 at 4:33 PM Oliver Collyer wrote: > > Can you clarify what you mean by "static variables are unacceptable". They're > all over the place in ffmpeg (random example > https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c > >

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Nicolas George
Oliver Collyer (2019-01-02): > Can you clarify what you mean by "static variables are unacceptable". They're > all over the place in ffmpeg (random example > https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c > >

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Nicolas George
Oliver Collyer (2019-01-02): > 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. There is nothing messy about it. Also, other parts of the project do things like that without fre

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Oliver Collyer
>>> +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 se

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Oliver Collyer
> On 2 Jan 2019, at 18:05, Nicolas George 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_en

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Nicolas George
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 = PTHREA

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Oliver Collyer
> On 2 Jan 2019, at 16:03, Oliver Collyer wrote: > > > >> On 2 Jan 2019, at 12:58, Oliver Collyer wrote: >> >> Hello >> >> So this time I'm reporting some potential memory leaks in the x265 encoder. >> There are a few hundred following a short encode session, but all seem to >> have the

Re: [FFmpeg-devel] Memory leaks using x265 encoder

2019-01-02 Thread Oliver Collyer
> On 2 Jan 2019, at 12:58, Oliver Collyer wrote: > > Hello > > So this time I'm reporting some potential memory leaks in the x265 encoder. > There are a few hundred following a short encode session, but all seem to > have the same call stack as below but varying allocation sizes. > > I am c