rawshift-hwdec's sequence seam accepts VideoConfig::Avcc and HwCodec::H264 — the API is final — but the VAAPI backend has no H.264 picture-parameter path, so video_decoder() refuses H.264 and available_video_codecs() does not advertise it. This is deliberate: discovery that promises a session which then fails to open is worse than discovery that is narrow.
The driver side is ready — the runtime probe already tracks VAProfileH264ConstrainedBaseline / Main / High, and Caps::h264_any() reports them.
What it takes:
avcC parsing — parameter sets, lengthSizeMinusOne, and the optional High-profile tail that many muxers omit.- SPS/PPS/slice-header parsing — including a correct VUI HRD skip. A mis-skipped HRD silently corrupts
max_dec_frame_buffering, which corrupts output order.
- Scaling lists — these cannot be rejected the way the still HEVC path rejects them:
VAIQMatrixBufferH264 is mandatory and High-profile camera encoders routinely signal matrices. Needs scaling_list() plus fall-back rules A and B.
sys.rs additions — VAPictureH264, VAPictureParameterBufferH264, VASliceParameterBufferH264, VAIQMatrixBufferH264, each with the size_of/offset_of layout test the existing structs carry.slice_data_bit_offset — the highest-risk detail. Unlike HEVC's slice parameter buffer there is no companion slice_data_num_emu_prevn_bytes, so the offset must be expressed against the escaped NAL as submitted: 8 + rbsp_bit_pos + 8 * epb_count_within(rbsp_bit_pos / 8). This is the detail most likely to differ between iHD, i965, radeonsi and nvidia-vaapi-driver, so validate it on real hardware before building anything on top.
Scope note: field_pic_flag == 1 (PAFF) should be rejected explicitly, as docs/SUPPORT.md records — camera-origin H.264 is progressive, and paired-field reference management roughly doubles the state machine. MBAFF is fine; it is frame coding.
Follow-up to #39.
rawshift-hwdec's sequence seam acceptsVideoConfig::AvccandHwCodec::H264— the API is final — but the VAAPI backend has no H.264 picture-parameter path, sovideo_decoder()refuses H.264 andavailable_video_codecs()does not advertise it. This is deliberate: discovery that promises a session which then fails to open is worse than discovery that is narrow.The driver side is ready — the runtime probe already tracks
VAProfileH264ConstrainedBaseline/Main/High, andCaps::h264_any()reports them.What it takes:
avcCparsing — parameter sets,lengthSizeMinusOne, and the optional High-profile tail that many muxers omit.max_dec_frame_buffering, which corrupts output order.VAIQMatrixBufferH264is mandatory and High-profile camera encoders routinely signal matrices. Needsscaling_list()plus fall-back rules A and B.sys.rsadditions —VAPictureH264,VAPictureParameterBufferH264,VASliceParameterBufferH264,VAIQMatrixBufferH264, each with thesize_of/offset_oflayout test the existing structs carry.slice_data_bit_offset— the highest-risk detail. Unlike HEVC's slice parameter buffer there is no companionslice_data_num_emu_prevn_bytes, so the offset must be expressed against the escaped NAL as submitted:8 + rbsp_bit_pos + 8 * epb_count_within(rbsp_bit_pos / 8). This is the detail most likely to differ between iHD, i965, radeonsi and nvidia-vaapi-driver, so validate it on real hardware before building anything on top.Scope note:
field_pic_flag == 1(PAFF) should be rejected explicitly, asdocs/SUPPORT.mdrecords — camera-origin H.264 is progressive, and paired-field reference management roughly doubles the state machine. MBAFF is fine; it is frame coding.Follow-up to #39.