> On 2 Jan 2019, at 19:18, Steinar H. Gunderson <steinar+ffm...@gunderson.no> > 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) and memory that's not (almost always a leak). This sounds > like an example of the former. >
Thanks Steinar. Personally I would always want the tool I am using to tell me about memory allocations I had made and not freed, but I guess it partly comes down to personal taste! More importantly in this case though, according to the documentation it is necessary to call x265_cleanup() in order for the next encoder to be able to use a new CU size. Here is the original x265 ticket: https://bitbucket.org/multicoreware/x265/issues/110/add-an-api-to-reset-cached-variables-so <https://bitbucket.org/multicoreware/x265/issues/110/add-an-api-to-reset-cached-variables-so> I don't know whether encoders can be opened/closed in this manner with different CU sizes using the ffmpeg command line tool, but they could be for other applications linking to the ffmpeg libraries. So even if it's not deemed necessary to add an API for the purpose of avoiding spurious memory leak reports (fair enough), it might be useful for the above, whether though something similar to my patch or maybe just a simple global function. From the docs: https://x265.readthedocs.io/en/default/api.html <https://x265.readthedocs.io/en/default/api.html> (Search for x265_cleanup) Regards Oliver _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
