an.bench.environment

The environment tuple — the fields that decide whether two rows may be compared.

Split into two halves with different comparison rules, because the two sides of the pipeline were measured and their answers are opposite:

Render side — comparable on any machine. Both render paths, four machines (local arm64 macOS, macos-latest, ubuntu-latest x86-64, ubuntu-24.04-arm), 132 frames each: zero differing pixels and zero differing PNG bytes, across two different SwiftShader JIT backends. So the render-side metrics need no cross-machine band column, and the golden corpus can be a CI gate. Record the Chromium build and the launch argv verbatim — all four rasteriser configurations report a byte-identical UNMASKED_RENDERER_WEBGL string, so the renderer string is demonstrably blind to the choice it was proposed to guard.

Encode side — machine-scoped, not bandable. Same ISA + same x264 build is byte-identical; a different ISA moves the decoded stream a little (luma <=2.66% of samples); a different x264 build moves it by two orders of magnitude (up to 99.2% of samples, mean |d| 3.94, max 36). A band that wide would swallow flat_field_deviation’s entire crf18->23 signal. So --compare (an#40) must refuse rows whose x264_sei or isa differ, in the same way it refuses rows with a different scene_contract_sha256 — the number is uninterpretable, not good or bad.

an.bench.environment.environment_record(*, pix_fmt: str, x264_sei: str | None = None, browser: dict[str, Any] | None = None) → dict[str, Any]

Everything about this machine that could plausibly move a number.

browser lets the caller supply an already-taken probe. The golden gate needs the Chromium build before the run-level provenance is assembled — the path keys on it — and probing twice would launch a second browser and could, in principle, report a different build from the one that rendered.

pix_fmt is required and has no default, because it is a comparability key and the caller is the only one who can measure it. It must be the format the delivered files actually are — imageio.delivered_pix_fmt — and not a re-derivation, for the reason an#72 records: the delivered encode resolves its format from RenderContext.pix_fmt or the module global, so reading either one is a second source of truth that can disagree with the file, and this field is what bench-compare uses to decide whether two encode-side rows may be compared at all.

an.bench.environment.ffmpeg_identity() → dict[str, Any]

The ffmpeg build banner. Informational — the x264_sei is the key.

an.bench.environment.probe_browser() → dict[str, Any]

Launch Chromium with the render path’s own flags and read back its identity.

Never raises: a probe that crashes must not cost a caller a completed capture, and a recorded error is more honest than a missing field that reads as “nothing to report”.

an.bench.environment.runtime_sha256() → str

A digest of the JS runtime the renderer will stage, files and names.

Provenance, NOT a comparability key: the runtime is the code under test, and two rows rendered by different runtimes are exactly what an bench –compare exists to compare. What it buys is that a render-side mutation leaves a fingerprint in the row — before this, the disabled_aa lever had no way to prove it applied, and assert not report[“mutation_may_not_have_applied”] asserted nothing for it (an#41 review).

an.bench.environment.x264_sei(mp4: Path) → str | None

The encoder build + thread count, read straight out of the file.