Flagging expression options

Seed

An early sketch, not a list-ready patch.

The problem

AVOption metadata doesn’t say which string options are expression-valued. In drawtext, x and y are FFmpeg expressions while text is a literal string — but all three are AV_OPT_TYPE_STRING, indistinguishable from the metadata. There’s no flag that says “this option is fed to av_expr_parse().”

Why it matters for bindings

This extension validates expression options eagerly — it parses them with av_expr_parse() the instant the filter is constructed, so a bad expression throws at that line rather than deep in graph configuration. But because nothing flags expression-ness, that only works for options we hand-know to be expressions. To do it generally — and to offer expression-aware tooling (autocomplete, the variables/constants work, per-frame closures) for every expression option — we need the flag.

Implementation candidates

1. An AVOption flag — e.g. AV_OPT_FLAG_EXPR, set on options whose value is parsed as an expression. Tiny, additive, mirrors how other option facets are flagged.
2. Per-filter expression-option list — alongside the expression variables metadata, name which options accept them.

(1) is the smaller, more general win.

To investigate

• The AV_OPT_FLAG_* space and whether maintainers consider an option’s expression-ness part of the stable contract (it effectively is — these options have accepted expressions for years).
• Survey of which filters/options would carry the flag.

Status

Seed. Closely related to the expression variables & constants proposal — ideally landed together as one “expressions are first-class metadata” effort.