[FFmpeg-trac] #11104(ffmpeg:new): Impractical implicit pad connection rules

[FFmpeg]

#11104: Impractical implicit pad connection rules
--------------------------------+---------------------------------------
             Reporter:  ManDay  |                     Type:  enhancement
               Status:  new     |                 Priority:  wish
            Component:  ffmpeg  |                  Version:  git-master
             Keywords:          |               Blocked By:
             Blocking:          |  Reproduced by developer:  0
Analyzed by developer:  0       |
--------------------------------+---------------------------------------
 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 by parts 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.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11104>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker