Memory leak in MPEG2 encoder with all versions >= 2.8

[jdemeulenaere]

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.

[Carl Eugen Hoyos]

Please test current FFmpeg git head and provide valgrind output for all leak reports. This will also include the (required) complete, uncut console output.

[jdemeulenaere]

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)

[Carl Eugen Hoyos]

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.