remade_ffmpeg_rs: Three Fixes Behind One Red AV2 Test

A red cargo test is rarely one bug. On 16 October 2026 the remade_ffmpeg_rs debug suite was red, and the first reading treated two of the failures as the same defect. They were not. Three libraries were each doing one honest thing that the test harness could not survive: the AV2 adapter, the AV2 decoder it calls, and the AVIF adapter's choice of assembly.

The field note for the whole pipeline is remade_ffmpeg_rs. The still-image and decoder notes beside this fix are rusty_av2d and rusty_av2f. The program those crates belong to is The Importance of Remade With Rust.

One red test was three defects

The suite is how remade_ffmpeg_rs promises that a hostile or truncated file becomes an error, not a dead process. Debug builds are stricter than release builds on purpose. Overflow checks and input checks are supposed to shout. They are not supposed to shout at a valid frame, and they are not supposed to kill the process in a way a test cannot catch.

An empty packet aborted the process

The fuzzer's truncate mutation can produce an empty packet. rff-codec-av2 was handing that packet straight to rusty_av2d. The decoder's input check requires a size greater than zero and no larger than half of usize::MAX. On a failed check, under debug assertions, that macro aborts the process. catch_unwind cannot contain an abort. The existing random-bytes test added one to every length, so it never sent zero bytes, and the empty case stayed invisible until the fuzzer made one. On Windows that abort showed up as exit code 0xc0000409.

A valid still underflowed in debug

The second failure looked like the same crash and was not. rusty_av2d 0.2.11, the newest release at the time of the fix, computes a GDF stripe base by subtracting one from the stripe index before it adds. On the first stripe of every GDF frame, valid input included, that subtraction underflows a usize. A release build wraps to the address the C reference reaches with a negative offset, and the still decodes byte for byte. A debug build with overflow checks panics. The line people had been calling an abort is an ordinary panic. The abort was the empty packet. The docs had merged those two sentences. They are separate now.

What each library does now

The repair stays inside the adapter and the workspace profile. It does not pretend the upstream decoder has already published a new formula, and it does not turn assembly on for a target whose crate cannot compile it.

The AV2 adapter refuses the bad packet

rff-codec-av2 now rejects an empty packet, and a packet larger than half of usize::MAX, with Error::InvalidData before rusty_av2d sees it. That guard runs in every build, not only in debug. It matches the guard rff-codec-avif already uses for rusty_av1d. A new test, empty_packet_is_an_error_not_an_abort, sends a zero-length packet and expects that error, then checks the decoder is still usable. A truncated file is an error the caller can handle. It is not a reason for the process to end.

The valid-frame underflow is handled beside that, not inside it. Until rusty_av2d publishes an add-before-subtract fix, the remade_ffmpeg_rs dev profile turns overflow checks off for that one package only: [profile.dev.package.rusty_av2d] overflow-checks = false. Release already wraps to the intended address. Dev and test builds now match that release arithmetic, so a green debug suite is not a lie about the bytes. The block is marked for deletion when the upstream fix ships. It is not a general license to disable overflow checks anywhere else.

AVIF assembly stays on x86_64

The third defect never touched a pixel. The published rusty_av1d 1.2.0 package excludes every C header, but its ARM assembly includes one of those headers. Enabling the asm feature therefore fails on every ARM target: Apple Silicon, Linux arm64, and Windows ARM64. rff-codec-avif now enables rusty_av1d assembly on x86_64 only. ARM decodes AVIF with the pure-Rust kernels until a release ships the missing header. rusty_av1e, the encoder behind the same still-image path, does not include that header, so it keeps assembly everywhere it already did. The AV1 toolkit note is rusty-av1-toolkit.

That split is the kind of fix a pure-Rust media stack has to make in public. The fast path stays on when the published crate can build it. The portable path stays correct when it cannot. Nobody papers over a missing file by skipping the ARM CI leg.

What a builder should take from the green suite

After the change, on Windows, debug, with --locked: the rff-codec-av2 unit tests passed 5 of 5, av2f_still passed 4 of 4 and matched the reference bytes, and fuzz_robustness passed 2 of 2 with exit code 0. The same robustness test had been aborting. Same pictures. A process that returns.

remade_ffmpeg_rs is the pipeline those pictures move through: decode, encode, transcode, mux, probe, without a C FFmpeg in the product. A household camera that must keep frames in the house still needs a decoder that fails closed on a short packet. That product surface is dldeploy.com, and the deployment note is dldeploy in the wild. The argument that a "local" camera can still leak a live view is the local camera that still left the house. When the same pipeline is placed on a mesh instead of a laptop, the home is mata.network, and the field note is MATA.NETWORK in the wild. The map is Vision.

The Monday test

Open a debug test run and refuse to call two red lines the same bug until you have named the input that produced each one. An empty packet, a valid frame, and a target that cannot compile are three tickets. Then ask whether the adapter returns an error the caller can catch, whether a debug panic is firing on bytes release already decodes correctly, and whether an assembly feature is enabled on an architecture the published crate can actually build. If all three answers are yes, the suite is allowed to be green.

Where to look next

remade_ffmpeg_rs, rusty_av2d, rusty_av2f, rusty-av1-toolkit, source Remade-With-Rust/remade_ffmpeg_rs, household cameras dldeploy.com, mesh home mata.network.