Opened 4 months ago

Last modified 4 months ago

#11104 new enhancement

Impractical implicit filter connection rules

Reported by: ManDay Owned by:
Priority: wish Component: avfilter
Version: git-master Keywords: filter_complex
Cc: MasterQuestionable Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by ManDay)

The current rules for connecting non-explicitly connected pads within a linear filter chain could be improved by inverting the order of consumption (implicit before explicit) to allow for better, textual representation of pipelines. Status quo is:

Within a linear filter chain (i.e. a filter complex where filters are only separated by ,, but not ;) F1[o1],[i1][i2]F2, input pads of a filter F2 will be connected in order to the pads [i1][i2] specified before filter. If, after that process, there remain unconnected pads for F2, they will be connected to the unnamed output pads of the preceeding filter F1.

NB: If the preceeding filter's unnamed output pads do not exactly match, an error will occur.

In practice, we often want to construct filter complexes which adjoin input data in a certain sense. Examples:

  • We want to overlay a set of videos onto a background:
                  [video a] [video b]
                      ↓         ↓
    [background]--→overlay--→overlay--→...
    
  • We want to concatenate audio or video to start at given timestamps:
                       [audio 1]       [audio 2]
                          ↓               ↓
    [no audio]--→apad--→concat--→apad--→concat--→...
    

What these examples have in common is that there is a primary pipeline into which sidestreams are merged. The filter themselves are (sensibly) such that the primary data is the first argument.

That clashes with the order of consumption, because now our textual representation has to look like:

  • [background][video a] overlay [background+video a]; [background+video_a][video_b] overlay
  • [no audio] apad [no audio padded]; [no audio padded][audio 1] concat, apad [audio 1 padded]; [audio 1 padded][audio 2] concat

It is necessary to explicitly name the intermediate pads on the primary pipeline. If the order of consumption were reversed, we could express such pipelines more naturally as

  • [background][video a] overlay, [video b] overlay
  • [no audio] apad, [audio 1] concat, apad, [audio 2] concat

I've also heard people saying that they are confused by the current consumption order, which I think is also an artefact of this, because y, [x] f amounts to y [y]; [x][y] f which flips the order of x and y on the input.

Change History (3)

comment:1 by ManDay, 4 months ago

Description: modified (diff)

comment:2 by ManDay, 4 months ago

Description: modified (diff)

comment:3 by MasterQuestionable, 4 months ago

Cc: MasterQuestionable added
Component: ffmpegavfilter
Keywords: filter_complex added
Summary: Impractical implicit pad connection rulesImpractical implicit filter connection rules

͏    "implicit before explicit" (prioritized reading of implicitly assigned filter output)
͏    Would you highlight the rationale for such practice?

Note: See TracTickets for help on using tickets.