[FFmpeg-trac] #5485(ffmpeg:new): Memory leak in MPEG2 encoder with all versions >= 2.8

[FFmpeg]

#5485: Memory leak in MPEG2 encoder with all versions >= 2.8
-------------------------------------+-------------------------------------
             Reporter:               |                     Type:  defect
  jdemeulenaere                      |                 Priority:  important
               Status:  new          |                  Version:
            Component:  ffmpeg       |  unspecified
             Keywords:  memory leak  |               Blocked By:
  mpeg2 encoder                      |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 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.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5485>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker