Summary
When Dolby Vision Profile 8.4 (dvvC, BL signal compatibility HLG) and SMPTE ST 2094-40 with T.35 oriented code 0x0003 (HLG+) are both present, MediaInfo labels the ST 2094 half as HDR10+ Profile A instead of HLG+.
The same ST 2094-40 SEI bitstream, remuxed without dvvC, is correctly labelled HLG+ compatible.
Related: #2536 (HLG+ support).
MediaInfo version
MediaInfo Command line
MediaInfoLib - v26.05
(Windows x64 CLI from MediaArea; also reproduced with the same lib in our bundled copy.)
Expected
HDR format : Dolby Vision, Version 1.0, Profile 8.4, ..., HLG compatible / SMPTE ST 2094 App 4, Version 1, HLG+ compatible
Transfer characteristics : HLG
HDR_Format_Compatibility should be something like: HLG / HLG+
Actual
HDR format : Dolby Vision, Version 1.0, Profile 8.4, dvhe.08.07, BL+RPU, no metadata compression, HLG compatible / SMPTE ST 2094 App 4, Version HDR10+ Profile A, HDR10+ Profile A compatible
Transfer characteristics : HLG
Codec configuration box : hvcC+dvvC
Inform fields:
| Field |
Value |
HDR_Format |
Dolby Vision / SMPTE ST 2094 App 4 |
HDR_Format_Compatibility |
HLG / HDR10+ Profile A |
HDR_Format_Version |
1.0 / 1 |
transfer_characteristics |
HLG |
colour_primaries |
BT.2020 |
BitDepth |
10 |
Control (same SEI, no dvvC)
Remux the HEVC access units to a plain hvc1 MP4 (no Dolby Vision configuration box). MediaInfo then reports:
HDR format : SMPTE ST 2094 App 4, Version 1, HLG+ compatible
Transfer characteristics : HLG
Codec configuration box : hvcC
| Field |
Value |
HDR_Format |
SMPTE ST 2094 App 4 |
HDR_Format_Compatibility |
HLG+ |
HDR_Format_Version |
1 |
So the ST 2094-40 payload is accepted as Profile A and the HLG→HLG+ rewrite works when Dolby Vision is absent.
Bitstream proof (T.35 header)
Prefix SEI, user_data_registered_itu_t_t35, first bytes of payload:
B5 00 3C 00 03 04 01 ...
│ │ │ │ └ application_version = 1
│ │ │ └ application_identifier = 4 (ST 2094 App 4)
│ │ └ oriented_code = 0x0003 ← HLG / ST 2094-40 (not 0x0001 PQ HDR10+)
│ └ provider_code = 0x003C
└ country_code = 0xB5
Present on every sampled frame. No 0x0001 T.35 App 4 messages in the file.
Per HDR10+/HLG+ docs:
0x0001 → ST 2094-40 when transfer is PQ
0x0003 → ST 2094-40 when transfer is HLG (HLG+)
Likely cause
In File__Analyze_Streams_Finish.cpp the HLG+ rewrite only runs when the entire compatibility string starts with "HDR10":
if (Retrieve(..., Video_HDR_Format_Compatibility).rfind(__T("HDR10"), 0)==0
&& ( ... || transfer != PQ || ... ))
{
if (transfer == HLG && Compatibility.rfind("HDR10+ Profile A", 0)==0)
Fill(..., "HLG+");
else
Clear(...);
}
With Dolby Vision 8.4 first, compatibility is HLG / HDR10+ Profile A, which does not start with HDR10, so the ST 2094 half is never rewritten to HLG+.
Suggested fix: apply the HDR10+ Profile A → HLG+ rewrite per /-separated HDR format slot (when that slot is ST 2094 App 4 / Profile A and transfer_characteristics is HLG), instead of only when the concatenated string begins with HDR10.
Secondary display quirk: the human-readable line shows Version HDR10+ Profile A for the ST 2094 half even though HDR_Format_Version is 1.0 / 1.
How the sample was produced
- Source: iPhone HEVC Main 10, Dolby Vision Profile 8.4, transfer HLG (
arib-std-b67).
- Measure HLG pictures → HDR10+ Profile A JSON (scene MaxScl / distributions).
- Inject ST 2094-40 SEI with oriented code
0x0003 into the existing bitstream without stripping NAL 62 / dvvC.
Samples
Attached / linked:
dv84_hlgplus_short.mov — DV 8.4 + HLG+ SEI (hvcC+dvvC) → MediaInfo shows HDR10+ Profile A for ST 2094.
same_sei_no_dvvc.mp4 — same SEI access units, no dvvC → MediaInfo shows HLG+.
Happy to re-upload or trim further if needed.
Summary
When Dolby Vision Profile 8.4 (
dvvC, BL signal compatibility HLG) and SMPTE ST 2094-40 with T.35 oriented code0x0003(HLG+) are both present, MediaInfo labels the ST 2094 half as HDR10+ Profile A instead of HLG+.The same ST 2094-40 SEI bitstream, remuxed without
dvvC, is correctly labelled HLG+ compatible.Related: #2536 (HLG+ support).
MediaInfo version
(Windows x64 CLI from MediaArea; also reproduced with the same lib in our bundled copy.)
Expected
HDR_Format_Compatibilityshould be something like:HLG / HLG+Actual
Inform fields:
HDR_FormatDolby Vision / SMPTE ST 2094 App 4HDR_Format_CompatibilityHLG / HDR10+ Profile AHDR_Format_Version1.0 / 1transfer_characteristicsHLGcolour_primariesBT.2020BitDepth10Control (same SEI, no
dvvC)Remux the HEVC access units to a plain
hvc1MP4 (no Dolby Vision configuration box). MediaInfo then reports:HDR_FormatSMPTE ST 2094 App 4HDR_Format_CompatibilityHLG+HDR_Format_Version1So the ST 2094-40 payload is accepted as Profile A and the HLG→HLG+ rewrite works when Dolby Vision is absent.
Bitstream proof (T.35 header)
Prefix SEI,
user_data_registered_itu_t_t35, first bytes of payload:Present on every sampled frame. No
0x0001T.35 App 4 messages in the file.Per HDR10+/HLG+ docs:
0x0001→ ST 2094-40 when transfer is PQ0x0003→ ST 2094-40 when transfer is HLG (HLG+)Likely cause
In
File__Analyze_Streams_Finish.cppthe HLG+ rewrite only runs when the entire compatibility string starts with"HDR10":With Dolby Vision 8.4 first, compatibility is
HLG / HDR10+ Profile A, which does not start withHDR10, so the ST 2094 half is never rewritten toHLG+.Suggested fix: apply the HDR10+ Profile A → HLG+ rewrite per
/-separated HDR format slot (when that slot is ST 2094 App 4 / Profile A andtransfer_characteristicsis HLG), instead of only when the concatenated string begins withHDR10.Secondary display quirk: the human-readable line shows
Version HDR10+ Profile Afor the ST 2094 half even thoughHDR_Format_Versionis1.0 / 1.How the sample was produced
arib-std-b67).0x0003into the existing bitstream without stripping NAL 62 /dvvC.Samples
Attached / linked:
dv84_hlgplus_short.mov— DV 8.4 + HLG+ SEI (hvcC+dvvC) → MediaInfo showsHDR10+ Profile Afor ST 2094.same_sei_no_dvvc.mp4— same SEI access units, nodvvC→ MediaInfo showsHLG+.Happy to re-upload or trim further if needed.