#5118 closed defect (duplicate)
leak with native encoders when receive container'ed input
Reported by: | Roger Pack | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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!
Change History (2)
comment:1 by , 9 years ago
Resolution: | → needs_more_info |
---|---|
Status: | new → closed |
comment:2 by , 9 years ago
Resolution: | needs_more_info → duplicate |
---|
Ok sorry I missed those somehow. Seems to be a dupe of https://trac.ffmpeg.org/ticket/4899 moving conversation there, thank you!
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.