Opened 4 years ago
Last modified 4 years ago
#8491 new defect
Memory utilization increases infinitely with mp4 muxing
Reported by: | Oleg | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | mov |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
I want to mux h264 stream into mp4 container. Memory usage of ffmpeg process increases infinitely over time .
For example, I tried to mux 1920x1080 stream repeatedly many times into one output file. Rate of muxing was ~26000 fps. Memory utilization increased by 200MB in 90 sec.
See chart in attachments (1920x1080, 60 fps, 6hrs, memory utilization increased by 80MB).
If I try to mux into flv container (-f flv "out.flv"), I don't observe this issue.
How to reproduce:
% ffmpeg -i test.h264 -c:v copy -f mp4 "out.mp4"
I measure memory usage with Windows Task Manager and with Performance Monitor.
ffmpeg-20200115-0dc0837 for Windows (nightly build)
Attachments (3)
Change History (9)
by , 4 years ago
by , 4 years ago
comment:1 by , 4 years ago
Summary: | Memory utilization increase with mp4 muxing → Memory utilization increases infinitely in with mp4 muxing |
---|
comment:2 by , 4 years ago
Summary: | Memory utilization increases infinitely in with mp4 muxing → Memory utilization increases infinitely with mp4 muxing |
---|
comment:3 by , 4 years ago
Component: | undetermined → avformat |
---|---|
Keywords: | mov added; memory mux mp4 removed |
I tested the provided command line with the sample you attached and only see a memory footprint of 32MB:
$ ffmpeg -benchmark -i test.h264 -c:v copy -f mp4 "out.mp4" ffmpeg version N-96463-g2bae3da79e Copyright (c) 2000-2020 the FFmpeg developers built with gcc 9 (SUSE Linux) configuration: --enable-gpl --enable-gnutls --enable-libx264 --enable-libx265 --enable-libaom libavutil 56. 38.100 / 56. 38.100 libavcodec 58. 66.100 / 58. 66.100 libavformat 58. 35.104 / 58. 35.104 libavdevice 58. 9.103 / 58. 9.103 libavfilter 7. 71.100 / 7. 71.100 libswscale 5. 6.100 / 5. 6.100 libswresample 3. 6.100 / 3. 6.100 libpostproc 55. 6.100 / 55. 6.100 Input #0, h264, from 'test.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 1200k tbn, 120 tbc Output #0, mp4, to 'out.mp4': Metadata: encoder : Lavf58.35.104 Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 60 tbr, 1200k tbn, 1200k tbc Stream mapping: Stream #0:0 -> #0:0 (copy) Press [q] to stop, [?] for help [mp4] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly frame= 500 fps=0.0 q=-1.0 Lsize= 2267kB time=00:00:08.34 bitrate=2226.6kbits/s speed=2.22e+03x video:2261kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.266425% bench: utime=0.004s stime=0.000s rtime=0.004s bench: maxrss=31928kB
comment:4 by , 4 years ago
Hi
Please try to read input file repeatedly many times.
smth like that:
ffmpeg -f concat -i "input.txt" ...
where input.txt contains (e.g. 5000 lines):
file 'test.h264' file 'test.h264' file 'test.h264' ... file 'test.h264'
I think issue will appear in this case.
follow-up: 6 comment:5 by , 4 years ago
Replying to olpipi:
If I try to mux into flv container (-f flv "out.flv"), I don't observe this issue.
They are different, it is a property of mov (mp4) output that it needs to allocate memory to record the track clusters, this is increasing over time.
comment:6 by , 4 years ago
Replying to cehoyos:
They are different, it is a property of mov (mp4) output that it needs to allocate memory to record the track clusters, this is increasing over time.
So is this normal that memory footprint grows infinitely?
If I use 32bit ffmpeg, it will crash after 4GB memory would be used, wouldn't it?
Could you please point where these "track clusters" are used in code?
input stream