[asoulliereHT]

Summary

Adds single-threaded FFmpeg 5.1.10 cores to the fork, built from the same hardened dependency pins as the MT 8.1.2 cores. The driver: cross-origin isolation (COOP/COEP) required by the MT core breaks popup-based auth (Facebook login) in the consumer, and clipping-tool-ui already forces -threads 1 to dodge an emscripten pthread-layer deadlock, so MT parallelism was not being used.

Why 5.1: fftools requires threads from FFmpeg 6.0 onward (ffmpeg_deps gains threads at n6.0 configure; pthread_create is unconditional in ffmpeg_demux.c/ffmpeg_mux.c), so the 5.1 LTS branch (5.1.10, 2026-06-21, still receiving backports) is the last single-thread-capable frontend.

What's in here

• src/fftools-5.1/: the pre-scheduler 5.1-era vendored fftools, resurrected from the chore/phase-0-baseline tree.
• Version-parameterized build: FFMPEG_VERSION flows Makefile → Dockerfile → ffmpeg-wasm.sh, selecting the FFmpeg tag and the fftools generation. The ARG is scoped to the ffmpeg-base stage so MT and ST builds share the dependency-builder cache.
• copy variant (make prd-st-copy → packages/core-copy): --disable-everything plus mov/mpegts/concat demuxers, mp4 muxer, h264/aac parsers+decoders, and the copy-path bsfs. No encoders, no external libs, no GPL. 2.6 MB wasm (full ST is 22.8 MB), sized to clipping-tool-ui's two -c copy commands.
• Non-COI test lane: scripts/serve.js --no-coi on port 3001; the ST pages assert crossOriginIsolated === false so the lane cannot silently run isolated. The inert COOP/COEP <meta> tags are removed.
• Vetting suites:
  • npm run test:cliptool / test:cliptool:copy: clipping-tool-ui's runClipExport and runClipStitch argv verbatim (including ffconcat + option ignore_editlist 1, -avoid_negative_ts make_zero, +negative_cts_offsets+faststart) against synthesized short-GOP H.264+AAC TS segments, with stream-presence assertions.
  • npm run test:st:probe: multi-input filtergraphs (overlay, xfade, concat filter) complete on ST 5.1 — the 8.x deadlock is scheduler-specific, confirming FORK.md's hypothesis; capability map updated per engine.
  • npm run test:perf:st / test:perf:mt: 1080p60 2s x264 re-encode: MT default 5.7s, MT -threads 1 20.9s, ST 22.9s.

Test results

• ST full core: 13/13 browser tests passing, non-isolated.
• ST copy core (2.6 MB): both verbatim production commands passing, non-isolated, outputs stream-verified (h264+aac).
• MT suites untouched and unaffected (test:all unchanged on port 3000).

Notes for review

• A vetting lesson is baked into the suite: the repo's single-keyframe 1s fixture plus size-only assertions let an audio-only export pass silently (input -ss past the only keyframe drops all non-key packets under -c copy). The cliptool suite synthesizes keyint=15 segments and asserts stream presence.
• ADR 0001 (MT-only) is not superseded by this PR; this is the evidence-gathering build. ADR 0002 should accompany the consumer cutover (release the copy core, bump fetch-ffmpeg-core.mjs, drop COOP/COEP, thread: false).
• Known cost to keep on the record: 5.1 gives up three majors of mov/mpegts demuxer/muxer fixes; recommend one vetting pass against a real archive segment before flipping the vendor pin.

Vetting record: ~/vault/docs/ffmpeg.wasm/plans/2026-08-13 st-5.1.10-core.md

🤖 Generated with Claude Code

[asoulliereHT]

Panel review (Danny/streaming, Keanu/build+CI, Bruce/QA, Jet/docs — Liam and Harrison excluded: no auth/input-surface or ABI/contract changes in this diff). 16 raw findings, deduplicated to 11 threads below; all verified against the working tree before posting.

Two findings could not anchor (lines outside the PR diff):

• [correctness] Jet (Docs): FORK.md's H1 (# FloSports fork — FFmpeg 8.1.2 (MT-only)) and opening paragraph still assert MT-only while the body now documents two ST 5.1.10 cores. Anyone who reads the first two lines and stops walks away with the wrong model of the fork. Fix the title and lede.
• [cleanup] Jet (Docs): The "Release variants" section still says "Each release ships two MT cores" and the vendoring section lists only MT tarballs — true, but a reader who just learned about the 2.6 MB copy core will go looking for a release asset that does not exist. State plainly that the ST cores are local-build/vetting-only until CI attaches them.

Convergence worth noting: three reviewers independently flagged the zero-CI-coverage gap, and two independently flagged the missing duration/start assertions — both are the load-bearing threads in this review.

[asoulliereHT]

Review (from the consuming app's side)

Approve. The st-build-and-test lane is the strongest consumer guarantee in the stack: it runs clipping-tool-ui's verbatim commands (TS+m4a window export, video-only, stitch via ffconcat with ignore_editlist) against the copy core on a non-isolated server asserting crossOriginIsolated === false, and the release job now needs it — the v0.15.0 MT-only-release failure mode is structurally closed. LGPL gate on the copy core and the honest ADR annotation (falsified bullets named with evidence) are both appreciated.

Findings:

1. FORK.md says the ST asset ships "from v0.15.1", but it actually shipped via the re-pointed v0.15.0. Recommend cutting v0.15.1 from the branch head: matches the doc and repairs the immutable-tags producer contract (the consumer's fetch script pins tag+SHA and now documents the re-point as a one-time exception). clipping-tool-ui's pin bump is a three-line change on our side.
2. This PR states fftools require threads from 6.0; clipping-tool-ui's comments say 7.0 (sourced from a stale branch comment). Yours is the researched claim — the correction lands on the consumer side.
3. Nit: the copy core's trim enables h264,aac decoders in a -c copy-purpose build. If they're load-bearing (probing?), a one-line comment would protect them from the next trimmer; if not, they're free size.

🤖 Generated with Claude Code