Add HDR detection (HDR10, HDR10+, HLG, Dolby Vision 1/2, SL-HDR1/2/3, HDR Vivid, combinations)

[Salem874]

Summary

Add identification and classification of HDR (High Dynamic Range) video formats so video files can be sorted/organized by HDR type. Detection must be safe (no false-positives on PQ-graded SDR / wide-gamut SDR / mislabeled files) and accurate (use the most authoritative signal available — bitstream SEI > container atom > metadata string).

Architectural note — primary work lives upstream. Detection enums and logic belong in meedya-codecs (MeedyaSuite-core), not duplicated in MeedyaManager. meedya-codecs/src/hdr.rs already defines HdrFormat with 7 variants (Hdr10, Hdr10Plus, DolbyVision, DolbyVisionHdr10, Hlg, Pq10, Sdr). This issue tracks (a) MM-side consumption: classify/rule-engine/UI integration, and (b) gaps in the upstream enum that need separate upstream PRs. See parent epic MWBMPartners/MeedyaSuite-core#9.

Formats in scope

8+ HDR formats grouped by family. Status column indicates whether HdrFormat already covers the format upstream.

Static-metadata HDR

Format	Container/codec signal	Authoritative signal	Upstream status
HDR10	HEVC Main 10 + transfer = PQ (ST 2084)	VUI transfer_characteristics = 16 + SEI mastering_display_colour_volume (ST 2086) + SEI content_light_level_info (MaxCLL / MaxFALL)	Covered by Hdr10
PQ10	HEVC + PQ transfer but no mastering metadata	transfer_characteristics = 16 without SEI ST 2086	Covered by Pq10

Dynamic-metadata HDR

Format	Container/codec signal	Authoritative signal	Upstream status
HDR10+	HEVC + SEI user data registered (T.35)	SEI T.35 country code 0xB5 (US) + provider code 0x003C (Samsung) + provider-oriented code 0x0001 + application identifier 4	Covered by Hdr10Plus
Dolby Vision (Profiles 5, 7, 8.1, 8.2, 8.4)	Codec four-CC dvhe / dvh1 / dav1 (AV1 DV) OR dvcC / dvvC config box on HEVC base	DV configuration box version + profile/level/RPU presence	Covered by DolbyVision (without profile granularity)
Dolby Vision 2	Codec configuration v2 box	DV config box v2 signature	NOT IN UPSTREAM — needs new variant
HDR Vivid (CUVA HDR, GY/T 358-2022, Chinese standard)	HEVC + SEI user data registered (T.35)	SEI T.35 country code 0xB5 + provider code 0x0026 (CUVA) + identifier byte 0x05	NOT IN UPSTREAM — needs new variant

HLG family

Format	Container/codec signal	Authoritative signal	Upstream status
HLG (Hybrid Log-Gamma, ARIB STD-B67)	HEVC/AV1 with HLG transfer	transfer_characteristics = 18 in VUI	Covered by Hlg

Advanced HDR by Technicolor (ETSI TS 103 433)

Format	Container/codec signal	Authoritative signal	Upstream status
SL-HDR1	SDR base layer + SEI HDR reconstruction metadata	SEI sl_hdr_info per ETSI TS 103 433-1 + base transfer = SDR (BT.709)	NOT IN UPSTREAM
SL-HDR2	PQ HDR + SEI dynamic metadata	SEI sl_hdr_info per ETSI TS 103 433-2 + base transfer = PQ	NOT IN UPSTREAM
SL-HDR3	HLG HDR + SEI dynamic enhancement	SEI sl_hdr_info per ETSI TS 103 433-3 + base transfer = HLG	NOT IN UPSTREAM

Combinations (dual-layer / nested)

Format	Authoritative signal	Upstream status
Dolby Vision + HDR10 (DV profile 7 / 8.1 with HDR10 base)	DV config box AND SEI ST 2086 both present	Covered by DolbyVisionHdr10
Dolby Vision + HDR10+	DV config box AND HDR10+ SEI both present	NOT IN UPSTREAM
HLG + HDR10+ (rare but possible)	HLG VUI + HDR10+ SEI	NOT IN UPSTREAM

Detection ladder — apply in order, take the FIRST authoritative match

Detection should use the most authoritative available signal:

1. Bitstream-level SEI / VUI signals (most authoritative):
   • VUI transfer_characteristics → PQ (16), HLG (18), BT.709 (1), BT.2020 (14/15)
   • SEI mastering_display_colour_volume (ST 2086) presence → HDR10 (when paired with PQ transfer)
   • SEI content_light_level_info → confirms HDR10
   • SEI T.35 with Samsung provider code → HDR10+
   • SEI T.35 with CUVA provider code → HDR Vivid
   • SEI sl_hdr_info → SL-HDR1/2/3 (variant determined by sl_hdr_mode_value)
2. Container codec four-CC (highly authoritative):
   • dvhe / dvh1 / dav1 sample entry → Dolby Vision
   • dvcC / dvvC configuration box → Dolby Vision (and version 2 if config v2)
3. Container colr box — nclx payload transfer/matrix coefficients corroborate VUI; prof payload provides ICC profile hint.
4. MediaInfo / ffprobe codec strings — useful for confirmation, NOT primary signal.
5. Filename / metadata strings — NEVER use to override bitstream signals.

Safety — false positives we must NOT produce

1. PQ-transfer SDR ≠ HDR10. A PQ-graded SDR test pattern has PQ transfer but typically lacks mastering_display_colour_volume SEI. Require both PQ + ST 2086 for Hdr10; PQ-without-metadata is Pq10.
2. BT.2020 wide-gamut SDR ≠ HDR. BT.2020 colour primaries can appear on SDR content; HDR requires a PQ or HLG transfer function, not just BT.2020 primaries.
3. Dolby Vision profile detection must NOT silently degrade to HDR10 when the DV layer is unparseable — emit Confident: Hdr10 only if HDR10 SEI is present independently. If only DV config is detected and the base layer is unknown, emit Confident: DolbyVision and note in source_signal.
4. HDR10+ requires verified SEI provider code, not just any T.35 SEI. Other T.35 user-data SEI types exist (closed captions, AFD, etc.).
5. HDR Vivid requires CUVA-specific SEI bytes. Don't classify based on filename hints (*hdr_vivid*.mkv).
6. Dual-format combinations — a file with both DV configuration and HDR10 SEI is DolbyVisionHdr10, NOT separately reported as DolbyVision + Hdr10 in the same MediaQuality slot.

Accuracy — confidence levels

• Confident — bitstream SEI / VUI matched (ladder rung 1)
• Likely — container codec four-CC matched (rung 2) but SEI not parsed
• Possible — MediaInfo / ffprobe string only (rung 4)
• Hint — filename / user tag (NEVER routed in rules)

Proposed Changes

1. Use upstream HdrFormat directly

use meedya_core::codecs::hdr::HdrFormat;

2. Add HDR field to MM video classification

pub struct VideoProperties {
    // … existing fields …
    pub hdr: Option<HdrDetection>,
}

pub struct HdrDetection {
    pub format: HdrFormat,
    pub confidence: HdrConfidence,
    pub source_signal: &'static str,    // "sei_mdcv", "dvcC_v2", "cuva_t35", "sl_hdr_info_mode2" …
    /// For combinations (e.g. DV+HDR10+), the secondary format.
    pub overlay: Option<HdrFormat>,
}

3. Rule engine + filetype registry

• hdr_format rule variable (string against HdrFormat::to_string()).
• is_hdr boolean shortcut.
• Filetype registry: hdr_capable: true flag per container.

4. Test fixtures

Per format covered upstream, an integration test asserting the right HdrFormat. Negative controls:

• PQ-graded SDR clip (must classify as Pq10, not Hdr10)
• BT.2020 SDR clip (must classify as Sdr)
• HDR10 with DV enhancement (must classify as DolbyVisionHdr10, not split into two)

Upstream gaps requiring separate upstream PRs

These items are missing from meedya-codecs::hdr::HdrFormat and need PRs against MeedyaSuite-core before MM can route on them. Filed as upstream issue alongside this one:

1. Dolby Vision 2 — DolbyVision2 variant
2. SL-HDR1 / SL-HDR2 / SL-HDR3 — three variants for Advanced HDR by Technicolor
3. HDR Vivid — HdrVivid variant (CUVA HDR)
4. DV + HDR10+ combination — DolbyVisionHdr10Plus
5. HLG + HDR10+ combination — HlgHdr10Plus (rare; lower priority)

Open questions / blockers

1. Dolby Vision profile granularity — should profile (5 / 7 / 8.1 / 8.2 / 8.4) be a sub-field of HdrDetection (source_signal) or distinct enum variants? Recommendation: sub-field; the codec is "Dolby Vision" regardless of profile.
2. HDR Vivid licensing — Chinese national standard; check IP terms before bundling a decoder dep. Detection-only (no decode) avoids most licensing concerns.
3. SL-HDR detection on muxed streams — if SL-HDR base layer is HLG and ALSO carries HDR10+ SEI, which wins? Recommendation: report SL-HDR3 (most-specific signal) and note HDR10+ in overlay.
4. MediaInfo coverage — does MediaInfo expose enough HDR signal info for SL-HDR / HDR Vivid / DV2? Verify in detection backend selection.

Affected Files

• crates/mm-core/src/classify/mod.rs — MediaQuality HDR integration
• crates/mm-core/src/classify/hdr.rs (new) — detection ladder consuming upstream
• crates/mm-core/src/metadata/mod.rs — VideoProperties::hdr: Option<HdrDetection>
• crates/mm-core/src/filetype_registry.rs — HDR capability flag per container
• crates/mm-core/src/rule_engine/functions.rs — hdr_format / is_hdr variables
• crates/mm-core/config/filetypes.json5 — format registry entries
• No MM-side bitstream parsing — upstream's meedya-codecs does it via MediaInfo / ffprobe per MeedyaSuite-core#9.

Labels

Enhancement, M5-Metadata-Providers, mm-core, cross-repo (upstream-blocked)

[Salem874]

Decision log — open question resolved

HDR Vivid → detection only

"HDR Vivid detection only"

HDR Vivid (CUVA HDR, GY/T 358-2022) added upstream as a classification variant only. No decoder integration, no licensing of the CUVA spec needed. Detection uses the SEI T.35 payload (country=0xB5, provider=0x0026 (CUVA), identifier 0x05) — that signal can be inspected without licensing the spec, same as HDR10+ T.35 SEI inspection.

requires_license() for HdrVivid returns false (we're not decoding / re-encoding). The doc comment notes that decoding / re-encoding HDR Vivid would require CUVA engagement, but classification doesn't.

Tracked upstream: MWBMPartners/MeedyaSuite-core#38 (with HDR Vivid section).

Other open questions in the issue body remain open

• Q: Dolby Vision profile granularity (5 / 7 / 8.1 / 8.2 / 8.4) — recommended sub-field, decision still pending
• Q: SL-HDR mode-byte parsing for mode-1/2/3 disambiguation — implementation-time concern
• Q: MediaInfo SL-HDR / HDR Vivid / DV2 signal coverage — verify at detection-backend selection time

These are implementation concerns for the eventual meedya-codecs SEI-parsing PR rather than blockers on enum design.

Updated effort estimate

MM-side work is unblocked once these 5+ upstream variants land (DolbyVision2, SlHdr1, SlHdr2, SlHdr3, HdrVivid, DolbyVisionHdr10Plus). Until then, the existing 7-variant HdrFormat covers 4 of the 8+ formats in this issue:

• ✅ Covered now: Hdr10, Hdr10Plus, DolbyVision, DolbyVisionHdr10, Hlg, Pq10, Sdr
• 🔜 Pending upstream PR: DolbyVision2, SlHdr1, SlHdr2, SlHdr3, HdrVivid, DolbyVisionHdr10Plus, optionally HlgHdr10Plus