Function decode_frames 

pub fn decode_frames(
    configuration: &VideoDecoderConfig,
    samples: &[EncodedVideoSample],
    limits: &Limits,
    frames: u64,
) -> Vec<u8> 

Decodes frames frames of samples and stops at the decoded Picture.

Issue #220: the public decoder’s submit returns RGBA, so a whole-frame benchmark through it measures decoding plus the colour conversion of HevcStageInputs::run_color_convert — a third of the interval, which until issue #219 gave it a kernel had no vector path at all and diluted every scalar-versus-SIMD ratio taken off those groups. This is the same decode without that tail: it drives the same HevcDecoder over the same access units and collects its pictures instead of converting them, so the difference between this and the end-to-end group is the conversion and nothing else about how the bitstream is handled.

Returns a fold over every decoded sample, for the harness’s bit-exactness guard — the same fold decode_frames applies to the converted bytes, so neither group pays for identifying its output more than the other does. Pins no instruction set; the caller selects the arm through crate::simd::set_override exactly as for an end-to-end decode.

Panics

Panics if the configuration is not decodable or if samples does not yield frames frames — a benchmark measuring less work than it reports would be worse than a failure. Decodes frames frames of samples all the way out to RGBA.

The end-to-end half of the issue #220 split, and the counterpart to decode_pictures: same decoder, same access units, same frame count, same output fold — the only difference is the picture_to_rgba pass on each decoded picture, which is what makes the gap between the two groups the conversion rather than an artefact of how each arm identifies its output.

Panics

Panics under the same conditions as decode_pictures.