Dynamic-pad port counts

Seed

An early sketch, not a list-ready patch — captured so the workaround in the extension has a documented upstream end-state.

The problem

A dynamic-pad filter decides how many pads it has from an option read during init — split’s outputs, asplit’s outputs, concat’s n — not from static metadata. There’s a flag (AVFILTER_FLAG_DYNAMIC_OUTPUTS / _INPUTS) saying a filter is dynamic, but nothing that says how many pads a given configuration will produce without actually creating and initialising the filter.

Why it matters for bindings

FilterNode::outputs() has to return one stream per output pad — so we need the count at call time, before any graph exists. With no metadata for it, the extension currently allocates a throwaway filter instance, applies the options, inits it, and reads nb_outputs (ff_filter_output_count in graph.c). It works, but it means spinning up (and tearing down) a real filter just to ask “how many pads?”, and it requires a complete-enough option set to init.

Implementation candidates

1. Expose the controlling option in metadata — a field on AVFilter linking a dynamic pad group to the option that sizes it (e.g. split → outputs), so a binding reads the option value and knows the count. Additive.
2. A pad-count query that doesn’t fully init — a helper that computes the pad count from a filter + its options without building a usable instance.
3. Curated supplement — if upstream prefers not to encode this, a small maintained map of filter → controlling option (the handful of dynamic-pad filters) shipped with bindings; least desirable, but documents the alternative.

To investigate

• How dynamic-pad filters create pads in init (libavfilter/vf_split.c, vf_concat.c) and whether the count is derivable from options pre-init.
• Whether the existing AVFILTER_FLAG_DYNAMIC_* flags could carry an associated option reference.

Status

Seed. The extension works today via init-probe; this would remove the throwaway instantiation.