mirror of
https://github.com/FFmpeg/FFmpeg.git
synced 2026-01-12 00:06:51 +08:00
929a2ced9b
In an ideal world, a filtergraph like `-i A -i B ... -filter_complex concat` would only keep resources in memory related to the file currently being output by the concat filter. So ideally, we'd open and fully decode A, then open and fully decode B, and so on. Practically, however, fftools wants to get one frame from each input file in order to initialize the filter graph (buffersrc parameters). So what happens currently is that fftools will request a single frame from each input A, B, etc that is plugged into the filtergraph. When using frame threading, the design of the decoder (ff_thread_receive_frame) is that it will not output any frames until we have received enough packets to saturate all threads. This, however, forces the decoder to buffer at least as many frames for each input file as we have threads, before outputting anything. By decoding the first frame synchronously, we avoid this issue and allow configuring the filter graph more quickly and without wasting excess resources on frames that will not (yet) be used.