leak with native encoders when receive container'ed input

[Roger Pack]

Summary of the bug:
How to reproduce (in one line...):
In my particular case, input from an mpegts file, and re-encode to mpeg4 video. Here is a one liner equivalent (you could optionally create the .ts file before hand):

% ./ffmpeg_g  -f lavfi -i color=c=red:size=10x10 -f mpegts - | ./ffmpeg_g -i - -vcodec mpeg4 -f null out
ffmpeg version N-77595-g77eeaa2 Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 7.0.2 (clang-700.1.81)
  configuration: --enable-libx264 --enable-gpl
  libavutil      55. 11.100 / 55. 11.100
  libavcodec     57. 21.100 / 57. 21.100
  libavformat    57. 21.100 / 57. 21.100
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 22.100 /  6. 22.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
ffmpeg version N-77595-g77eeaa2 Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 7.0.2 (clang-700.1.81)
  configuration: --enable-libx264 --enable-gpl
  libavutil      55. 11.100 / 55. 11.100
  libavcodec     57. 21.100 / 57. 21.100
  libavformat    57. 21.100 / 57. 21.100
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 22.100 /  6. 22.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, lavfi, from 'color=c=red:size=100x100':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 100x100 [SAR 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc
[mpeg2video @ 0x7fb0b380c400] too many threads/slices (8), reducing to 7
Output #0, mpegts, to 'pipe:':
  Metadata:
    encoder         : Lavf57.21.100
    Stream #0:0: Video: mpeg2video (Main), yuv420p, 100x100 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 25 fps, 90k tbn, 25 tbc
    Metadata:
      encoder         : Lavc57.21.100 mpeg2video
    Side data:
      unknown side data type 10 (24 bytes)
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
Input #0, mpegts, from 'pipe:':
  Duration: N/A, start: 1.440000, bitrate: N/A
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 100x100 [SAR 1:1 DAR 1:1], max. 104857 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Output #0, null, to 'out':
  Metadata:
    encoder         : Lavf57.21.100
    Stream #0:0: Video: mpeg4, yuv420p, 10x10 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc57.21.100 mpeg4
    Side data:
      unknown side data type 10 (24 bytes)
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> mpeg4 (native))
[mpeg2video @ 0x7fc134801600] too many threads/slices (8), reducing to 7
frame=26469 fps=5289 q=2.0 Lsize=    6101kB time=00:17:38.72 bitrate=  47.2kbits/s speed= 212x    
video:2217kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 175.244614%
frame=26469 fps=5319 q=2.0 Lsize=N/A time=00:17:38.76 bitrate=N/A speed= 213x    
video:334kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

Watch the RAM usage of the receiving FFmpeg ramp up and never go down (suspected leak) until all memory exhausted. Valgrind reports some "indirectly lost" leaks. This one took me like two days to figure out. Current work around is to use libx264 video encoder instead, no leak. If it receives from "raw" input like testsrc, similarly, no leak. If you use the video encoding codec of mpeg2video it seems to similarly leak. If you use input from an "avi" then it appears to similarly leak. Seems to be reproducible in both windows and OS X (at least). Thanks!

[Carl Eugen Hoyos]

Feel free to reopen this ticket if you can provide valgrind output (this is always required for tickets about memleaks) but I believe this is a duplicate, see the important tickets / regressions.

[Roger Pack]

Ok sorry I missed those somehow. Seems to be a dupe of ​https://trac.ffmpeg.org/ticket/4899 moving conversation there, thank you!