[FFmpeg-trac] #10550(avfilter:new): complex_filtergraph (trim, concat) memory leak

[FFmpeg]

#10550: complex_filtergraph (trim, concat) memory leak
-------------------------------------+-------------------------------------
             Reporter:  Kurt         |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avfilter
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
  filter_complex trim memleak        |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Kurt):

 I have spent some time trying to debug and fix this without luck.
 trim_filter_frame() gets called for the trim that starts at 200s,
 correctly dropping (and av_frame_free'ing) frames till pts=90000*200, then
 passing on frames till 220s, then setting the eof status and never being
 called again. (The code path in trim_filter_frame() that would drop frames
 after 220s is never called.)
 No reason to leak memory as far as I can see ...

 Looking at the filtergraph with the debugger, I see
 [0] ff_vf_trim(200s-220s) "Parsed_trim_0"
 [1] ff_vf_setpts "Parsed_setpts_1"
 [2] ff_vf_trim(400-440s) "Parsed_trim_2"
 [3] ff_vf_setpts "Parsed_setpts_3"
 [4] ff_avf_concat "Parsed_concat_4"
 [5] ff_vf_trim(1440-1500s) "Parsed_trim_5"
 [6] ff_vf_setpts "Parsed_setpts_6"
 [7] ff_avf_concat "Parsed_concat_7"
 There's more which does not directly stem from my passed filtergraph:
 [8] ff_vsrc_buffer "graph 0 input from stream 0:2"
 [9] ff_vf_trim(0-AV_NOPTS_VAL) "trim_in_0_2"
 [10] ff_vsrc_buffer "graph 0 input from stream 0:2"
 [11] ff_vf_trim(0-AV_NOPTS_VAL) "trim_in_0_2"
 [12] ff_vsrc_buffer "graph 0 input from stream 0:2"
 [13] ff_vf_trim(0-AV_NOPTS_VAL) "trim_in_0_2"
 [14] ff_vsink_buffer "out_0_0"
 [15] ff_vf_format "format"

 I have not yet spent a lot of time looking at filters 8 .. 15, but the
 existence of the trims there are surprising to me.
 After [0] is in EOF (after 220s), [9]+[10] continue to run, but we may
 somehow miss an EOF check that frees the frames that go nowhere?
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10550#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker