Opened 8 years ago
Closed 8 years ago
#5485 closed defect (invalid)
Memory leak in MPEG2 encoder with all versions >= 2.8
Reported by: | jdemeulenaere | Owned by: | |
---|---|---|---|
Priority: | important | Component: | undetermined |
Version: | unspecified | Keywords: | leak regression |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
I observed a memory leak when transcoding a looping video sample from h264 to MPEG-2 during a few hours/days. Ffmpeg takes more and more memory (~6-7GB after 3 days) until the computer lacks memory and kills the process.
This bug happens regularly when transcoding a specific channel received from my TV provider (from which the sample was taken) and is 100% reproducible from the sample.
I think that this bug has been introduced since version 2.8, because it does not happen for versions <= 2.7.6 (tested with each release between 2.7 and 2.7.6) and it also happens on all versions >= 2.8 (tested with each release between 2.8 and 3.0.1).
What I tested:
I converted the sample from H264 to MPEG-2 with the versions I mentioned earlier. The leak is present with versions >= 2.8.
Also, it does not happen when copying the video format or converting it to H263, so I think that the bug comes from the MPEG-2 encoder.
How to reproduce:
It happens only with the video stream from 2 specific channels of my TV provider (out of 24) so you need my video sample to reproduce it.
First you have to stream loop the sample (link: https://taktik.media/FZakKpl7fq) into the network, e.g. with tsplay or ffmpeg 3.0+ :
% tsplay -loop -udp france3-nodata.ts 239.255.1.111 1234
Then to reproduce the bug, you have to transcode the video with ffmpeg >= 2.8 (I took the releases from http://ffmpeg.org/releases/) :
% ffmpeg -i 'udp://239.255.1.111:1234?fifo_size=2000000&overrun_nonfatal=1' -map 0 -sn -ignore_unknown -c:a copy -c:v mpeg2video -f mpegts -flush_packets 0 'udp://239.255.11.111:8888?pkt_size=1316' ffmpeg version 2.8 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 5.3.0 (Alpine 5.3.0) configuration: --enable-version3 --enable-gpl --enable-nonfree --enable-small --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libvpx --enable-libtheora --enable-libvorbis --enable-libopus --enable-libass --enable-libwebp --enable-librtmp --enable-postproc --enable-avresample --enable-libfreetype --enable-openssl --disable-debug libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100
When using versions <= 2.7.6, the process stalls at 566MB RAM (as shown in top
). There is no upper limit when using versions >= 2.8 (you will have to wait a few hours to observe that behaviour).
This is quite problematic for us because we convert 24 channels 24/24h, and this bug always happens with two of those after a few hours.
Thanks in advance.
Change History (3)
comment:1 by , 8 years ago
Component: | ffmpeg → undetermined |
---|---|
Keywords: | regression added; memory mpeg2 encoder removed |
comment:2 by , 8 years ago
This is the valgrind output with the snapshot version of http://ffmpeg.org/releases/ (2016-04-27 19:22) :
==18517== Memcheck, a memory error detector ==18517== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==18517== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==18517== Command: ./ffmpeg -i udp://239.255.1.111:1234?fifo_size=2000000&overrun_nonfatal=1 -map 0 -sn -ignore_unknown -c:a copy -c:v mpeg2video -f mpegts -flush_packets 0 udp://239.255.11.170:8888?pkt_size=1316 ==18517== ==18517== Invalid free() / delete / delete[] / realloc() ==18517== at 0x4C92B0E: free (vg_replace_malloc.c:530) ==18517== by 0x4020168: ??? (in /lib/ld-musl-x86_64.so.1) ==18517== Address 0x4e9a180 is in a rw- mapped file /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so segment ==18517== ffmpeg version N-79679-g6f784c1 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 5.3.0 (Alpine 5.3.0) configuration: --enable-version3 --enable-gpl --enable-nonfree --enable-small --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libvpx --enable-libtheora --enable-libvorbis --enable-libopus --enable-libass --enable-libwebp --enable-librtmp --enable-postproc --enable-avresample --enable-libfreetype --enable-openssl --disable-debug libavutil 55. 22.101 / 55. 22.101 libavcodec 57. 38.100 / 57. 38.100 libavformat 57. 34.103 / 57. 34.103 libavdevice 57. 0.101 / 57. 0.101 libavfilter 6. 44.100 / 6. 44.100 libavresample 3. 0. 0 / 3. 0. 0 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 0.101 / 2. 0.101 libpostproc 54. 0.100 / 54. 0.100 ==18517== Warning: set address range perms: large range [0x8fc0080, 0x1f654e80) (undefined) [...] ==18610== ==18610== LEAK SUMMARY: ==18610== definitely lost: 0 bytes in 0 blocks ==18610== indirectly lost: 0 bytes in 0 blocks ==18610== possibly lost: 0 bytes in 0 blocks ==18610== still reachable: 166,369 bytes in 2,852 blocks ==18610== suppressed: 0 bytes in 0 blocks ==18610== ==18610== For counts of detected and suppressed errors, rerun with: -v ==18610== ERROR SUMMARY: 24 errors from 1 contexts (suppressed: 0 from 0)
comment:3 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
So there is no leak? Please remove --disable-debug
if you can provide a command line that allows to reproduce a memory leak.
If you want to reopen this ticket please provide complete, uncut console output as requested in comment:1.
Please test current FFmpeg git head and provide valgrind output for all leak reports. This will also include the (required) complete, uncut console output.