refactor hvc1 and hev1 to shared implementation, add hvc2 and hev2

[bradh]

I missed the ccst on hev1 the first time around, so its probably better to have a shared implementation. There are more boxes to go in (e.g. lhvC).

Took the opportunity to add hvc2 and hev2 which are the same (at least from https://mpeggroup.github.io/FileFormatConformance/?query=%3D%22hvc2%22 ).

If this works out, I'll do the avc2, avc3, and avc4 in the same way.

[coderabbitai]

Walkthrough

This pull request refactors HEVC atom handling by consolidating four HEVC sample entry types (Hvc1, Hvc2, Hev1, Hev2) through a new define_hevc_sample_entry macro in hvc1.rs. The standalone hev1.rs file is deleted and its implementation is now macro-generated. New variants Hev2 and Hvc2 are added to the Any enum to support additional HEVC codec types. A ccst field is introduced to the Hvcc struct and related test structures. The module exports are updated to remove the separate hev1 module declaration.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely summarizes the main changes: refactoring hvc1 and hev1 into a shared implementation while adding new hvc2 and hev2 variants.
Description check	✅ Passed	The description is directly related to the changeset, explaining the motivation (missed ccst field), the refactoring approach (shared implementation), and future plans.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/moov/trak/mdia/minf/stbl/stsd/hevc/hvc1.rs`:
- Around line 3-70: The match arms in the decode_body of the
define_hevc_sample_entry macro incorrectly use `.into()` to set Option fields
(e.g., hvcc, btrt, colr, pasp, taic, fiel, ccst); replace those assignments with
explicit Some(atom) (e.g., Any::Hvcc(atom) => hvcc = Some(atom)) inside the impl
Atom::decode_body for the generated types so each extracted atom is
idiomatically wrapped in Option; leave the
hvcc.ok_or(Error::MissingBox(Hvcc::KIND)) check as-is and do not change other
logic in encode_body or the Visual/Hvcc fields.

[kixelated]

Seems fine. Although I wonder if it would be possible to have an enum for the FourCC instead of copy-paste with a macro. Maybe I'll mock something up tomorrow?

[ocrete]

Shouldn't the ccst box be available for basically all image/video codecs, not just HEVC boxes ?
I wonder if it shouldn't be in the as an Option<Ccst> inside of Visual ?

[bradh]

Shouldn't the ccst box be available for basically all image/video codecs, not just HEVC boxes ?

It is available for Uncv and Hvc1, and Hev1 was intended but omitted. I see no reason why ccst can't be added for Av1 and Avc1 if that is required.

I wonder if it shouldn't be in the as an Option<Ccst> inside of Visual ?

Could be, but I'm not aware of anyone doing (say) VP9 as a HEIF image sequence. So I think it only makes sense to support it in codecs where its valid / common.

[ocrete]

Could be, but I'm not aware of anyone doing (say) VP9 as a HEIF image sequence. So I think it only makes sense to support it in codecs where its valid / common.

The code you added to to GStreamer's isomp4mux will happily produce image sequences with VP8 or VP9. The same would apply to the JPEG/J2K family as well

[kixelated]

Maybe I'll mock something up tomorrow?

I don't think I'll have time, and yeah it would be for naught if there are subtle differences between the boxes outside of the FourCC.

[bradh]

The code you added to to GStreamer's isomp4mux will happily produce image sequences with VP8 or VP9. The same would apply to the JPEG/J2K family as well

Perhaps the VP8/VP9 code should get fixed in gstreamer then.

JPEG and JPEG 2000 are valid (along with the AV1 and AVC cases).

[bradh]

I don't think I'll have time, and yeah it would be for naught if there are subtle differences between the boxes outside of the FourCC.

Are you OK with the macro implementation for now?

[ocrete]

The code you added to to GStreamer's isomp4mux will happily produce image sequences with VP8 or VP9. The same would apply to the JPEG/J2K family as well

Perhaps the VP8/VP9 code should get fixed in gstreamer then.

I tried to find in the various specs why VP8/VP9 image sequences wouldn't be valid, or MPEG-4 Visual (Part 2), or even H.263 ? Reading the spec, there doesn't seem to have any restrictions on which codecs can be used for image sequences stored in tracks.

[bradh]

I tried to find in the various specs why VP8/VP9 image sequences wouldn't be valid, or MPEG-4 Visual (Part 2), or even H.263 ? Reading the spec, there doesn't seem to have any restrictions on which codecs can be used for image sequences stored in tracks.

I think its "is this codec valid in HEIF"? ISO 23008-12:2025 makes that the case for HEVC (see Annex B), AVC (see Annex E), JPEG (see Annex H), VVC (see Annex L) and EVC (see Annex M). ISO 15444-16:2025 Section 7 covers JPEG 2000. AVIF covers that at https://aomediacodec.github.io/av1-avif/#image-sequences

I'm not aware of anything that makes VP8 or VP9 valid in HEIF. Equally, I'm not aware of anything that explicitly excludes them. I lean to "if its not in the standard, its outside it", although a different interpretation could well be valid.