On 9/1/22 13:26, Carl Eugen Hoyos wrote:
Am Do., 1. Sept. 2022 um 21:16 Uhr schrieb Jorge Villatoro via
ffmpeg-user :
If you'd like to call it something else that's fine with me, but it's clear
that the memory usage of the process escalates over time
Which is not unusual for applications
Am Do., 1. Sept. 2022 um 21:16 Uhr schrieb Jorge Villatoro via
ffmpeg-user :
>
> If you'd like to call it something else that's fine with me, but it's clear
> that the memory usage of the process escalates over time
Which is not unusual for applications writing multimedia files.
massif (another
On Thu, Sep 1, 2022 at 11:24 AM Carl Eugen Hoyos wrote:
> Am Do., 1. Sept. 2022 um 19:07 Uhr schrieb Jorge Villatoro via
> ffmpeg-user :
>
> > I've tried running valgrind on this process for a while but I'm not
> really
> > sure how to decipher the results other than that there doesn't appear to
On 9/1/2022 11:24 AM, Carl Eugen Hoyos wrote:
If valgrind does not show a memory there is no memory leak.
Probably; the tool is generally considered reliable but "never say never"
(this is why we test the testing tools).
A process may need more memory over time but that is not a leak.
Am Do., 1. Sept. 2022 um 19:07 Uhr schrieb Jorge Villatoro via
ffmpeg-user :
> I've tried running valgrind on this process for a while but I'm not really
> sure how to decipher the results other than that there doesn't appear to be
> an obvious leak.
If valgrind does not show a memory there is
Hi,
I believe that I've stumbled across a slow memory leak in the QSV encoder,
or possibly the underlying library I'm not really sure. I've been able to
see a slow leak (~50MB/hr in the worst case) in ffmpeg processes performing
an QSV encode where an identical configuration running a CUDA encode
