[FFmpeg-user] ffmpeg architecture question

Mark Filipak markfilipak.windows+ffmpeg at gmail.com
Fri Apr 17 09:02:10 EEST 2020

Thanks to pdr0 -at- shaw.ca, My quest for the (nearly perfect) p24-to-p60 transcode has concluded.

But remaining is an ffmpeg behavior that seems (to me) to be key to understanding ffmpeg 
architecture, to wit: The characteristics of frame traversal through a filter chain.

 From a prior topic:
Filter graph:

split[A]    select='not(eq(mod(n+1\,5)\,3))'       [C]interleave

What I expected/hoped:

split[A]         0 1 _ 3 4         [C]interleave 0 1 B 3 4  //5 frames
      [B]split[D] _ 1 _ _ _ [F]blend[D]               |
              [E] _ _ 2 _ _ [G]                       blend of 1+2

What appears to be happening:

split[A]         0 1 _ 3 4         [C]interleave 0 1 _ 3 4  //4 frames
      [B]split[D] _ _ _ _ _ [F]blend[D]
              [E] _ _ 2 _ _ [G]

The behavior is as though because frame 1 (see Note) can take the [A][C] path, it does take it & 
that leaves nothing left to also take the [B][D][F] path, so blend never outputs.
(Note: I originally wrote "frame n+1==1" but that was an error.)

I assume that frame numbers are assigned at the input of the filter chain as frames are encountered, 
and that the following actions occur.
Frame 0: Traverses [A][C] and is enqueued at [C].
Frame 1: Traverses [A][C] and is enqueued at [C] (see Proposition).
Frame 2: Traverses [B][E][G] and is enqueued at [G].
Frame 3: Traverses [A][C] and is enqueued at [C].
Frame 4: Traverses [A][C] and is enqueued at [C].

Proposition: Frame 1 could also traverse [B][D][F] and be enqueued at [F] but since it's already 
enqueued at [C], it does not do so.

Specifically, it appears that ffmpeg does not recurse the filter chain for frames that are already 
enqueued, thus Frame 1 is not enqueued at [F], thus 'blend' doesn't activate when Frame 2 arrives at 
[G], thus Frame 2 is never enqueued at [D] and never appears in the output of 'interleave'.

Is what I've written correct? Authoritative confirmation or correction of this architectural detail 
is desired.


More information about the ffmpeg-user mailing list