Summary
StreamBuffer::data_copy() strips header_size() bytes off the front of the frame ("excluding the header if one is present"). For H.264/H.265 key frames, that stripped header is where VDO carries the SPS/PPS (and VPS) parameter sets — so data_copy() on a key frame returns only the coded slice, without the parameter sets, and there is nothing in the current docs to signal this.
This is a genuine footgun: a caller that scans data_copy() bytes for SPS/PPS (to build an avcC/hvcC, an MP4 init segment, an SDP fmtp, etc.) will never find them, even though the stream is perfectly healthy.
Evidence
On an ARTPEC-6 / firmware-11 H.264 stream, for the IDR buffer:
frame_type = VDO_FRAME_TYPE_H264_IDR
header_size = Some(41)
as_slice()[..size()] head = 00 00 00 01 67 64 00 29 ... // 0x67 = SPS NAL, then PPS, then the IDR slice
data_copy() head = 00 00 00 01 65 ... // 0x65 = IDR slice only — SPS/PPS gone
So the parameter sets live entirely within the [0 .. header_size) region that data_copy() discards; as_slice()[..size()] is the full [SPS][PPS][IDR slice] Annex-B access unit.
Request
- Docs: on
data_copy() (and/or header_size()), note that on key frames the header contains the SPS/PPS/VPS parameter sets, and that as_slice() is the way to obtain them.
- Optional API: a small convenience like
parameter_sets() / header_bytes() returning the [0 .. header_size) slice would make the common "grab the codec config once" path obvious and hard to get wrong.
Context
Cost a few debugging cycles on real hardware (the stream looked fine, key frames arrived, but SPS/PPS never appeared) before header_size made it obvious. Filing so the next person doesn't repeat it. Happy to PR the doc note + accessor.
Summary
StreamBuffer::data_copy()stripsheader_size()bytes off the front of the frame ("excluding the header if one is present"). For H.264/H.265 key frames, that stripped header is where VDO carries the SPS/PPS (and VPS) parameter sets — sodata_copy()on a key frame returns only the coded slice, without the parameter sets, and there is nothing in the current docs to signal this.This is a genuine footgun: a caller that scans
data_copy()bytes for SPS/PPS (to build anavcC/hvcC, an MP4 init segment, an SDP fmtp, etc.) will never find them, even though the stream is perfectly healthy.Evidence
On an ARTPEC-6 / firmware-11 H.264 stream, for the IDR buffer:
So the parameter sets live entirely within the
[0 .. header_size)region thatdata_copy()discards;as_slice()[..size()]is the full[SPS][PPS][IDR slice]Annex-B access unit.Request
data_copy()(and/orheader_size()), note that on key frames the header contains the SPS/PPS/VPS parameter sets, and thatas_slice()is the way to obtain them.parameter_sets()/header_bytes()returning the[0 .. header_size)slice would make the common "grab the codec config once" path obvious and hard to get wrong.Context
Cost a few debugging cycles on real hardware (the stream looked fine, key frames arrived, but SPS/PPS never appeared) before
header_sizemade it obvious. Filing so the next person doesn't repeat it. Happy to PR the doc note + accessor.