forked from unom/punktfunk
enricobuehler
6c379f8fef
The HEVC twin of pf-vaadec's H.264 buffer layouts, measured the same way: the committed probe extended to cover va_dec_hevc.h, every size and offset read off real libva 2.23.0 headers and pinned as const assertions — VAPictureHEVC 28, VAPictureParameterBufferHEVC 604, VASliceParameterBufferHEVC 264, VAIQMatrixBufferHEVC 1016 — and every bit-field position read back out of a real header rather than counted by eye. The finding worth carrying: HEVC's reference plumbing is a THIRD convention, and this program has now been bitten by confusing two of them. Vulkan takes DPB SLOT indices in RefPicSetStCurrBefore/After/LtCurr. Writing reference-list positions there is what made HEVC unplayable on every driver until it was root-caused. DXVA takes positions into RefPicList[] in identically named arrays. VAAPI takes neither. It marks set membership as FLAGS on the DPB entries themselves — VA_PICTURE_HEVC_RPS_ST_CURR_BEFORE / _AFTER / _LT_CURR — and its per-slice RefPicList[2][15] holds INDICES INTO ReferenceFrames, not pictures and not surfaces. Three spellings of one idea, identical names on two of them, and different referents on all three. The conversion will say which it is writing, every time, and the docs now hold all three side by side. Two more asymmetries with the H.264 side, recorded where they will be read: ReferenceFrames is 15 entries here, not 16; and the offset is slice_data_byte_offset — BYTES, where H.264 wants bits — over the same definition. slice_data() is byte-aligned by byte_alignment(), so the parser's header_bit_size / 8 is exact rather than rounded, which the conversion will assert rather than assume. Tests cover the probe's measured bit patterns plus a disjointness sweep over every field of pic_fields and slice_parsing_fields — two probe vectors per word would not catch a shift typo that overlapped two neighbours, and these words are 20 and 14 fields wide.