Closed alexmbird closed 5 years ago
Can you try running r128gain without the album gain, and on a single core: r128gain -c 1 -r -o --ffmpeg-path=/usr/local/bin/ffmpeg --dry-run smash_mp3
or taskset -c 0 r128gain -r -o --ffmpeg-path=/usr/local/bin/ffmpeg --dry-run smash_mp3
?
Done - r128gain -c 1 -r -o --ffmpeg-path=/usr/local/bin/ffmpeg --dry-run smash_mp3
completed successfully in 14m.
Now if you run r128gain -a -r -o --ffmpeg-path=/usr/local/bin/ffmpeg --dry-run smash_mp3
, but on a directory with only 2 MP3 files in it, do you also run out of memory?
$ ls -l smash_mp3_2
total 9868
-rw-r--r-- 1 mock mock 3997630 May 16 09:57 101 - Mellon Collie And The Infinite Sadness.flac.mp3
-rw-r--r-- 1 mock mock 6106786 May 16 09:58 102 - Tonight Tonight.flac.mp3
r128gain -a -r -o --ffmpeg-path=/usr/local/bin/ffmpeg --dry-run smash_mp3
completes fine when only the first two tracks are present.
As a test I've used the time
command to measure peak memory usage for different numbers of tracks. To keep it fair I've used N copies of the same track rather than ones of differing length. Output is:
140.30user 2.75system 1:10.67elapsed 202%CPU (0avgtext+0avgdata 73420maxresident)k
282.14user 6.25system 2:25.26elapsed 198%CPU (0avgtext+0avgdata 191380maxresident)k
424.52user 10.26system 3:38.78elapsed 198%CPU (0avgtext+0avgdata 308972maxresident)k
564.45user 12.57system 4:52.70elapsed 197%CPU (0avgtext+0avgdata 426920maxresident)k
712.96user 17.63system 6:26.77elapsed 188%CPU (0avgtext+0avgdata 537228maxresident)k
It looks like memory usage scales linearly with the number of tracks. I wonder if the audio is being decompressed into ram and kept there.
My initial thought, was that it was a bug (memory leak) in FFmpeg triggered only for MP3 and the album gain filter chain (which is quite complex). But if the memory usage only linearly with the number of tracks, this does not seem to be the case.
The only question is why it is different between Opus and MP3 files. On my system the memory usage between both is very similar, with only a few percent of difference.
If you have time to spare, and are motivated to fix this, you can:
I am closing this issue because there is nothing I can do about the FFmpeg memory usage, but if you need help/guidance in your tests, I am still around.
I've been on the fence about reporting this one as the answer might be "quit trying to run r128gain on a Raspberry Pi". But since the behaviour varies by the content being analyzed I'll go ahead and report it.
This is for the following setup:
--enable-libopus
opus files
I run
r128gain -r -a -o --ffmpeg-path=/usr/local/bin/ffmpeg --dry-run smash_opus
. Memory usage is very low. Analysis takes about 12 minutes and r128gain completes successfully.mp3 files
I run
r128gain -r -a -o --ffmpeg-path=/usr/local/bin/ffmpeg --dry-run smash_mp3
. Then memory usage gets too high and it grinds to a halt, eventually failing with an error.Some things I have tried:
Failed to analyze file 'smash_mp3/210 - We Only Come Out at Night.flac.mp3': CalledProcessError Command '['/usr/bin/ffmpeg', '-hide_banner', '-nostats', '-threads:0', '1', '-i', 'smash_mp3/210 - We Only Come Out at Night.flac.mp3', '-filter_threads', '1', '-map', 'a', '-filter:a', 'aformat=sample_fmts=s16,replaygain,ebur128=framelog=verbose', '-f', 'null', '/dev/null']' returned non-zero exit status 1
, one per input file. Memory usage remains low and it fails immediately so this is probably an unrelated issue.Here's some detailed output:
And output with
-v debug
: