Move CI off an ffmpeg that dies reading MPEG-TS (#13849)
* Move CI off an ffmpeg that dies reading MPEG-TS
The pinned 7.0.2 static build segfaults on the runners as soon as it
is handed an MPEG-TS file: ffprobe on a file the segment muxer had
just written, and ffmpeg decoding a stream, both exit -11. Nothing in
the suite had ever read one, so this has been sitting under the pin
unnoticed. The only test that touched a `.ts` fed it the bytes
"transport-stream-bytes" and patched ffprobe out.
It is the machine, not the bytes and not the pin's integrity: the
binary CI runs hashes the same as a clean download, the same download
reads the same files here under the full suite in parallel and pinned
to four cores, the crash survives `-cpuflags 0`, and the runner is an
AMD EPYC 7763 where this box is a Xeon.
So both platforms move to 8.1.2, the Linux build from BtbN, since
johnvansickle has published nothing since 7.0.2. The backend suites
pass here against 8.1.2 as they do against 7.0.2 and 4.4.2.
* Check the ffmpeg archives before running them
Both are unpacked and then executed by every job that uses this
action, publishing included, and neither was checked against anything
beyond the HTTPS response. GitHub publishes a digest for each release
asset, so the two are pinned to theirs. The Linux one is the archive
the suites were run against.
* Mirror the ffmpeg builds into a bucket we own
The Linux pin was a BtbN daily build, and BtbN keeps only the last 14
of those, so the URL had roughly ten days left before CI started
failing on a 404 at whatever moment the Actions cache happened to
miss. Their month-end builds are kept for two years instead, and the
one from 2026-08-31 carries the same 8.1.2.
Pinning that would have bought two years and no more, so both
archives are now copies in a bucket we control. They are byte for
byte what the upstream releases serve, with a provenance.json beside
them recording the original URL, the upstream build commit and the
hash, and paths that are never rewritten. Neither BtbN nor GyanD
ships source next to its binaries, so source/ carries BtbN's build
recipe at the commit that produced this archive; every one of its 86
package scripts pins its own repository and commit.
The pin now lives in one step rather than being spread across the
cache key and two download steps, which is what let the archive hash
replace the hand-maintained -v1 suffix in the key. Changing a pin
now invalidates the cache on its own.
* Apply suggestion from @abidlabs
---------
Co-authored-by: Abubakar Abid <abubakar@huggingface.co>
