Skip to content

chore: regenerate FFmpeg bindings - #968

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
chore/regen-bindings-20260706-165852
Open

chore: regenerate FFmpeg bindings#968
github-actions[bot] wants to merge 1 commit into
mainfrom
chore/regen-bindings-20260706-165852

Conversation

@github-actions

@github-actions github-actions Bot commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

Auto-generated by CI CodeGen workflow.

Updates FFmpeg bindings for v5, v6, v7, v8 using pre-built Docker images with hardware filter support (VAAPI, OpenCL, etc.).

lucemia added a commit that referenced this pull request Aug 15, 2026
Codegen output reached main in two steps: merge the template change, then
merge a second bot PR carrying the regenerated bindings. Between them main
held generator code without matching output — and the second merge was
manual, so in practice that window never closed. #968 and #987 have been
open since July, which is why the core cache still shows April.

The generation was already happening at the right time and being thrown
away. `ci-codegen-versions.yml` runs its four generate jobs on every PR
touching the generator (~12 minutes of compute on PR #1005 alone), but
`create-pr` was gated on `github.event_name == 'push'`, so the PR's output
was discarded and regenerated after merge.

So apply it where the change is. On a same-repo PR the regenerated files
are committed straight to the PR branch, making the merge atomic. Pushes
and dispatches keep the create-PR path, since there is no branch to commit
back to. Fork PRs cannot be pushed to with GITHUB_TOKEN, so those fail with
the diff and instructions rather than silently dropping the output. The
apply logic itself stays single-sourced across all three paths.

Two honest consequences, documented in CONTRIBUTING rather than buried:
the bot pushes with GITHUB_TOKEN, which deliberately does not re-trigger
workflows, so a PR's other checks keep results from the pre-generation
commit (the generate job verifies imports, and main re-runs everything on
merge); and contributors will see a bot commit appear on their branch.

Also fixes a silent-omission bug in the pre-existing change detection:
`git diff --quiet` only inspects tracked files, so a newly generated module
— a new FFmpeg filter, or every file of a future v9 — was reported as "no
changes" and dropped. Verified locally: with an untracked new file,
`git diff --quiet` reports no changes while `git add -A && git diff --cached
--quiet` correctly reports changes. Detection now stages first.

Adds .gitattributes marking the generated bindings and cache as
linguist-generated, so committing output alongside a template change
collapses those files in review rather than burying the real diff.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TMvT2bzCPzJsK3wVa5BTBT
lucemia added a commit that referenced this pull request Aug 15, 2026
Consolidating onto ci-codegen-versions.yml dropped a step the deleted
codegen-regenerate.yml had: `uvx prek run --all-files` before committing.
prek's hooks cover ^(src/|packages/), so raw generator output is not
formatted and the bot committed it as-is.

The cost is almost entirely noise. For packages/v8/src/ffmpeg/streams/
video.py alone, the bot's output differed from main by 40,848 lines; after
`ruff format` it differs by 228. Across the branch that is 98 files /
330,446 insertions before formatting versus 64 files / 255,381 after, and
the remaining bulk is regenerated JSON cache, not code: the Python diff is
32 files, +58/-9.

Add the format step before change detection, so a formatting-only delta
does not register as a real change, and apply the formatter to the output
the bot already committed.

What the 58 Python lines actually contain, having checked:

- `vaapi_device` global option, gained because the CI image is a full
  VAAPI build (consistent with filters going 476 -> 549)
- the auto-generated header restored to 12 files that had lost it
- the iterative-traversal fix from b4d061f finally reaching v5/v6/v7.
  That commit fixed RecursionError and O(n^2) behaviour on filter graphs
  with 1000+ filters, but only packages/v8 was regenerated; v5, v6 and v7
  have carried the recursive version ever since because the regeneration
  PR was never merged. #968 and #987 sitting open since July is exactly
  this failure mode.

Public API is unchanged: streams/video.py has 329 methods before and
after, streams/audio.py 146, with none added or removed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TMvT2bzCPzJsK3wVa5BTBT
lucemia added a commit that referenced this pull request Aug 15, 2026
…ator+output atomically (#1005)

* fix(ci): consolidate codegen to one workflow and unstale published data

Binding generation has been unreliable because three workflows did the same
job and the primary one never worked.

`codegen-regenerate.yml` failed 100 out of 100 runs — it has never once
succeeded. Two sequential causes: `ref: v4` in its checkout, pointing at a
branch deleted when the v4 work merged into main (every generate job died
with "A branch or tag with the name 'v4' could not be found"), and then the
`git add` of gitignored paths fixed in 4ecc1d7. The failures stayed
invisible because `ci-codegen-versions.yml` succeeded on the same trigger.

The duplication also caused the breakage: `regen-bindings.yml` carries a
`git add -f` workaround for the gitignore bug, `codegen-regenerate.yml`
never got it, and that is exactly what killed it.

So: delete both redundant workflows. `ci-codegen-versions.yml` is a strict
superset — its path triggers cover `src/scripts/code_gen/**` (including
templates/), it uses the full custom builds for v7/v8 rather than
jrottenberg's `--enable-small` images, and it already uses second-resolution
branch names and `git add -A`. It is also the one that demonstrably works.

Second, and the part that reached users: `packages/data-v*` had not been
regenerated since f6ed3f8 (2026-04-03). Codegen writes cache to
`packages/core/.../cache/list/`, which is not shipped
(`include-package-data = false`, package-data is `py.typed` only), so
installed users read this data from the published `ffmpeg-data-vN` package —
which nothing updated. The drift is real, not theoretical:

    filters.json   core 2,417,509   shipped data-v8 2,152,131
    codecs.json    core   787,800   shipped data-v8   606,888

and it is internally inconsistent — `data-v8/filters.json` is byte-identical
to core's `filters_8_1.json` while its `codecs.json` matches neither
`codecs.json` nor `codecs_8_0.json`. The apply step now mirrors each
version's cache into `packages/data-v${ver}/.../cache/list/` under the
shipped (unsuffixed) names, so what is published is what was generated.

That mixing is explained by the artifact glob: `*_${version}_*.json` matches
sibling minors, so the v8 artifact picked up both `_8_0` and `_8_1` files.
Matrix entries now carry an explicit `ffmpeg-mm` (`8_0`) used for both the
upload glob and the mirror mapping.

Verified: the mirror logic was exercised against simulated artifacts —
v8 (8_0) and v5 (5_1) mirror to unsuffixed names with fresh content, a
version with no artifact is left untouched, and both edge cases (missing
`packages/data-vN`, artifact with no `filters_*.json`) warn and continue
without aborting under `bash -e`.

CONTRIBUTING's "Adding a New FFmpeg Version" section pointed at the deleted
workflow; it now documents the single-workflow flow, the `ffmpeg-mm` field,
and that newer majors need an image built here since jrottenberg stops at 8.0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TMvT2bzCPzJsK3wVa5BTBT

* fix(ci): apply generated output on the PR instead of after merge

Codegen output reached main in two steps: merge the template change, then
merge a second bot PR carrying the regenerated bindings. Between them main
held generator code without matching output — and the second merge was
manual, so in practice that window never closed. #968 and #987 have been
open since July, which is why the core cache still shows April.

The generation was already happening at the right time and being thrown
away. `ci-codegen-versions.yml` runs its four generate jobs on every PR
touching the generator (~12 minutes of compute on PR #1005 alone), but
`create-pr` was gated on `github.event_name == 'push'`, so the PR's output
was discarded and regenerated after merge.

So apply it where the change is. On a same-repo PR the regenerated files
are committed straight to the PR branch, making the merge atomic. Pushes
and dispatches keep the create-PR path, since there is no branch to commit
back to. Fork PRs cannot be pushed to with GITHUB_TOKEN, so those fail with
the diff and instructions rather than silently dropping the output. The
apply logic itself stays single-sourced across all three paths.

Two honest consequences, documented in CONTRIBUTING rather than buried:
the bot pushes with GITHUB_TOKEN, which deliberately does not re-trigger
workflows, so a PR's other checks keep results from the pre-generation
commit (the generate job verifies imports, and main re-runs everything on
merge); and contributors will see a bot commit appear on their branch.

Also fixes a silent-omission bug in the pre-existing change detection:
`git diff --quiet` only inspects tracked files, so a newly generated module
— a new FFmpeg filter, or every file of a future v9 — was reported as "no
changes" and dropped. Verified locally: with an untracked new file,
`git diff --quiet` reports no changes while `git add -A && git diff --cached
--quiet` correctly reports changes. Detection now stages first.

Adds .gitattributes marking the generated bindings and cache as
linguist-generated, so committing output alongside a template change
collapses those files in review rather than burying the real diff.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TMvT2bzCPzJsK3wVa5BTBT

* chore: regenerate FFmpeg bindings

Applied automatically by the CI CodeGen workflow so the generator
change and its output land in a single merge.

* fix(ci): push generated commit with a PAT so CI re-runs

Committing generated output onto the PR branch with GITHUB_TOKEN leaves the
PR unmergeable. GITHUB_TOKEN pushes deliberately do not start workflow runs,
and check runs are bound to a commit SHA — so the new head carries zero
checks rather than stale ones, and can never satisfy the required CI Status
gate.

Observed on this PR: after the bot's commit 29ca33f, `gh pr view` reported
`mergeable: MERGEABLE/BLOCKED, checks: 0`.

Push with CODEGEN_PAT (PAT or GitHub App token, repo scope) when available,
falling back to GITHUB_TOKEN with an explicit warning explaining why checks
will be missing. Documented as a required secret in CONTRIBUTING.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TMvT2bzCPzJsK3wVa5BTBT

* fix(ci): format generated output before committing it

Consolidating onto ci-codegen-versions.yml dropped a step the deleted
codegen-regenerate.yml had: `uvx prek run --all-files` before committing.
prek's hooks cover ^(src/|packages/), so raw generator output is not
formatted and the bot committed it as-is.

The cost is almost entirely noise. For packages/v8/src/ffmpeg/streams/
video.py alone, the bot's output differed from main by 40,848 lines; after
`ruff format` it differs by 228. Across the branch that is 98 files /
330,446 insertions before formatting versus 64 files / 255,381 after, and
the remaining bulk is regenerated JSON cache, not code: the Python diff is
32 files, +58/-9.

Add the format step before change detection, so a formatting-only delta
does not register as a real change, and apply the formatter to the output
the bot already committed.

What the 58 Python lines actually contain, having checked:

- `vaapi_device` global option, gained because the CI image is a full
  VAAPI build (consistent with filters going 476 -> 549)
- the auto-generated header restored to 12 files that had lost it
- the iterative-traversal fix from b4d061f finally reaching v5/v6/v7.
  That commit fixed RecursionError and O(n^2) behaviour on filter graphs
  with 1000+ filters, but only packages/v8 was regenerated; v5, v6 and v7
  have carried the recursive version ever since because the regeneration
  PR was never merged. #968 and #987 sitting open since July is exactly
  this failure mode.

Public API is unchanged: streams/video.py has 329 methods before and
after, streams/audio.py 146, with none added or removed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TMvT2bzCPzJsK3wVa5BTBT

* chore: regenerate FFmpeg bindings

Applied automatically by the CI CodeGen workflow so the generator
change and its output land in a single merge.

* fix: remove stray packages/v6/src/ffmpeg/v8 committed by mistake

This directory is a local artifact from an Apr 17 codegen run with a wrong
--outpath. It was untracked and hidden by the over-broad `ffmpeg/` ignore
rule until 4ecc1d7 anchored that rule, then got swept into this branch by a
`git add -A packages`. It is not part of the v6 bindings and nothing imports
it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TMvT2bzCPzJsK3wVa5BTBT

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants