enricobuehler 7f82bca9c0 fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list ...

A doc paragraph in `pic_av1.rs` wrapped so that "first at frame / 6. Releasing…"
put `6.` at the start of a line. rustdoc reads that as an ordered-list item
starting at 6, which makes the following unindented `///` line a lazy
continuation — `clippy::doc_lazy_continuation`, denied by `-D warnings`.

Reflowed so the number cannot begin a line. Prose is byte-identical in content;
only the wrap points move. No code, no behaviour.

WHY THIS MATTERS FOR THE TAG. `pf-dxvadec` is Windows-only, and no Windows leg
runs on a push to main — so main being green proves nothing about this. The
failure surfaces for the first time in a release tag's fan-out, which is exactly
what happened to the FIRST v0.23.0 tag: it went red on Windows clippy for this
same lint, and the cure was a tag re-point.

Caught pre-tag by re-running the lazy-continuation scanner over the tree while
preparing v0.25.0 (0 hits before this commit's parent merged the new decode
crates, 1 after). Cannot be verified by compiling here — the crate does not build
on macOS — so the evidence is the scanner plus the lint's own rule, not a clippy
run.

2026-08-08 01:25:59 +02:00

..

src

fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list

2026-08-08 01:25:59 +02:00

tests

fix(client): the H.264 twin was real — every low-delay picture decoded into a surface it predicted from

2026-08-07 22:09:44 +02:00

Cargo.toml

feat(client): native D3D11VA AV1 — wired, and four defects it exposed

2026-08-07 03:01:49 +02:00

layout-probe-av1.c

feat(dxvadec): M7's DXVA AV1 layouts, measured against Microsoft's own header

2026-08-06 18:26:02 +02:00