forked from unom/punktfunk
enricobuehler
3041d9bb43
The native D3D11VA rung had no pixel evidence at all. Its DXVA bytes were checked against libavcodec's own captured bytes, and its Intel bring-up proved the driver accepts the submission — but nothing had ever compared what came out. This is that comparison, against the same goldens and the same reference the Vulkan rung was held to: libavcodec's SOFTWARE decode, which is ground truth rather than a peer implementation, so the two rungs' verdicts are now directly comparable numbers. It reads back the DECODE surface, before the VideoProcessorBlt, so what is hashed is the half this rung is responsible for; the hand-off is the shared, field-proven half and is deliberately not in the measurement. Finding, recorded rather than papered over: this rung presents in DECODE order. It never consults AuPlan::dpb.outputs — submit blits setup_slot and returns. The native Vulkan rung keeps a display-order queue for exactly that reason, and libavcodec's D3D11VA rung reorders internally, so this rung differs from both. It cannot bite on punktfunk streams, which are zero-reorder and carry no B pictures, but that is a convention of our hosts rather than a structural guarantee, and a stream that did reorder would present out of order with nothing to say so. Both vendored vectors DO reorder — the H.265 one's first B picture at AU 3 is what localised the RPS slot defect — so a harness hashing in decode order would report a permutation against display-order goldens and read like a decoder fault. Instead each decoded surface is hashed against the PicId the planner gave it and the hashes are emitted in the planner's own output order. The reordering is the test's, done by the planner the rung already trusts, and `both_vendored_vectors_really_do_reorder` asserts the reason so the docs cannot go stale silently. The crop reads the chroma plane at RowPitch * texture height, not display height: the decode pool is aligned to the codec's granule and is taller than the picture. That is the 1088-row smear this project has already paid for. Two CPU guards run in ordinary CI. This file needs its own Annex-B splitter (pf-client-core does not depend on the vendored parser), and a splitter that disagreed with pf-bitstream's would fail on hardware as a frame-count mismatch that reads like a decoder defect; instead it fails on CPU, saying so. PF_DXVA_ADAPTER pins a GPU by description substring and every run prints the adapters it saw — .173 enumerates its AMD iGPU alongside the 4090, and which one answered is a fact worth printing rather than inferring. Hardware: H.264 and H.265 both 250/250 bit-identical on NVIDIA GeForce RTX 4090 and on the AMD Radeon iGPU, Windows. Gates: clippy -D warnings and the lib tests on Windows, the Linux container's clippy/tests/workspace check, and rustfmt.