[vitlav]

Summary

Fixes #6: muxing freshly encoded HEVC into Matroska fails because the backend reports VA_ENC_PACKED_HEADER_NONE, and FFmpeg then explicitly refuses to write a global header ("No global header will be written: … not muxable to some containers", vaapi_encode.c). Matroska requires hvcC extradata at write_header time, so hevc_vaapi → .mkv aborts. H.264 → MP4 only works by accident: the MP4 muxer extracts the in-band SPS/PPS from the first packet, which Matroska does not do for HEVC.

Changes

• report VA_ENC_PACKED_HEADER_SEQUENCE for VAConfigAttribEncPackedHeaders, so clients generate their own sequence headers and build container extradata from them;
• accept VAEncPackedHeaderParameterBufferType / VAEncPackedHeaderDataBufferType in buffer creation and encode rendering, discarding the payload — the stateful encoder already emits equivalent sequence headers in-band, and nothing can be spliced into its coded stream.

Note

The container extradata is client-generated (FFmpeg's own VPS/SPS/PPS), so it may not be byte-identical to the firmware's in-band headers; decoders pick up the in-band parameter sets.

Validation

Validated on Qualcomm SC7180 (TCL B220G, qcom-venus, together with #5): direct hevc_vaapi → Matroska muxing now succeeds without the extract_extradata remux workaround.

[nyanmisaka]

so it may not be byte-identical to the firmware's in-band headers

This causes the latest version of FFmpeg, when using -tag:v hvc1 with the MP4 muxer, to produce videos that fail to play in Safari, Firefox, and MPC-BE. This will also break the ability to generate cross-platform compatible fMP4 segments from encoded video using hlsenc muxer.

The out-of-band PS written by FFmpeg is inconsistent with the actual in-band PS, and the in-band PS is removed when hvc1 is used.

See also https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15529