@
Milhouse Just to offer an insight from a different POV, my crappo OS is not Libreelec,
and I use slightly different versions of some pieces of software and I rely on shared libraries (if that matters), but kodi codebase is the same (newclock5) and HEVC ffmpeg patches are the same.
I' ve just played elysium sample like 15 times - and yes, there is a leak here too,
the monitoring was done by bcmstat.sh.
The file was played from nfsv4 source, kernel fstab mount.
320MB ram assigned to GPU.
I use the tip of glibc release/2.26 branch, no MMAP_THRESHOLD set.
So if it's glibc bug - it's not fully fixed as of current tip of glibc 2.26 branch.
After 15 playbacks I still had 355,148 kB/49.4%,
however the situation here is a lot better than reported by others in this thread.
There results are inconclusive, on average full reproduction of the sample leaks ~24MB of ram, but sometimes after playback the ram is freed and after around 30 secs even more ram is freed and I get more free ram than before playback.
Here is how it looks when the ram is freed (this does not happen always):
Code:
#before playback
18:25:58 1200Mhz 500Mhz 0Mhz 58.00C (58.53C) 4,757 1,489 453 210M ( 70%) 355,816 kB/49.3% 0 -224 0 -388
#just before the end
18:27:02 1197Mhz 500Mhz 0Mhz 79.52C (80.59C) 4,652 1,258 210 136M ( 45%) 252,180 kB/64.1% 0 -84 -77,594,624 -104,024
#playback ended
18:27:04 1200Mhz 500Mhz 0Mhz 75.75C (80.59C) 4,796 24,330 9,894 210M ( 70%) 375,872 kB/46.4% +77,594,624 +123,692 0 +19,668
#30 seconds later
18:27:35 1200Mhz 500Mhz 0Mhz 65.53C (80.59C) 4,732 154 229 210M ( 70%) 390,944 kB/44.3% 0 +15,204 0 +34,740