forked from unom/punktfunk
enricobuehler
3f738a9989
A 2026-08-13 field report from the same RTX 5060 client asa02014ec: every AV1 session demoted to D3D11VA with "outside device caps: stream level (seq_level_idx 31) above the device's maxLevel (AV1 Std level 23)" — 4K120, NVIDIA, the hardware decoding the stream trivially on the D3D11VA rung it fell through to.a02014ecfixed the H.264/H.265 half of exactly this and left AV1 alone on the premise that "no over-declaration has been seen in the field"; the reporter's own log from that same day already showed otherwise. seq_level_idx is a 5-bit field. Annex A defines 0…23 (levels 2.0…7.3), reserves 24…30, and makes 31 the "maximum parameters" level — the spec's own way of saying the bitstream is NOT constrained to a level. StdVideoAV1Level stops at 7.3 = 23, so 31 has no Std code point and the index-coded comparison that holds across 0…23 says nothing here: 31 > 23 is true even of a device that decodes everything AV1 can name, which is what makes it useless as a capability test. We write no AV1 level on any host encode path, so whichever sentinel the vendor's encoder defaults to is what the client must accept. So the gate warns once and proceeds, like its H.265 sibling. Unlike H.265 there is nothing to clamp: StdVideoAV1SequenceHeader carries no level field, so the declaration never reaches the driver and cannot be invalid usage. The stream's real demands stay enforced where they are physical facts — coded extent and DPB depth, both checked at session build. Not verified on glass: no RTX 5060 here, and the reporter's box is the only one that has produced a seq_level_idx 31 stream. The unit test pins the arithmetic that made the refusal look reasonable.