#11104: Impractical implicit pad connection rules
-------------------------------------+----------------------------------
Reporter: ManDay | Owner: (none)
Type: enhancement | Status: new
Priority: wish | Component: ffmpeg
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+----------------------------------
Description changed by ManDay:
Old description:
> 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.
New description:
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.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11104#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
