MediaInfo v25.04 (MediaInfoLib - v25.04, Linux x86-64) reports no Dolby Vision at all on
a file whose every frame carries a Dolby Vision RPU, when the Matroska container is missing
the dvcC block addition mapping. ffprobe finds the RPU on the first frame it looks at.
I have 57 files in this state. They were all trimmed by a commercial tool that copies the
HEVC elementary stream but never writes the dvcC and hvcE elements, so the picture data
still has Dolby Vision in it and nothing in the container says so. MediaInfo then names them
HDR10 or HDR10+, and I use MediaInfo output to name my files, so 57 of them got named wrong.
What MediaInfo says
HDR_Format : SMPTE ST 2094 App 4
HDR_Format_Compatibility : HDR10+ Profile B
No Dolby Vision, no profile, nothing.
What is actually in the first two frames
ffprobe -v error -select_streams v:0 -show_frames -read_intervals '%+#2' -of json <file>
Content light level metadata
Dolby Vision Metadata
Dolby Vision RPU Data
HDR Dynamic Metadata SMPTE2094-40 (HDR10+)
Mastering display metadata
So this is a profile 7 stream: a Dolby Vision RPU and HDR10+ dynamic metadata in the
same elementary stream. MediaInfo reports the second and not the first.
The RPU is on every frame, not just the head. Counting NAL units over 20 seconds of one of
these files gives 483 type-62 (RPU) and 1133 type-63 (enhancement layer) units, one RPU per
frame — the same counts as the untrimmed source the file was cut from.
What separates a detected file from an undetected one
Only the container elements. mkvinfo on a file MediaInfo does detect:
+ Block addition mapping
+ Block addition ID type: 1685480259 (dvcC)
+ Block addition ID extra data: length 24, ...
+ Block addition mapping
+ Block addition ID type: 1752589125 (hvcE)
+ Block addition ID extra data: length 795, ...
On the undetected file both elements are absent. Same encoder, same profile, same RPU in
the bitstream.
The ask
Fall back to the bitstream when the container says nothing: if dvcC is absent and the HEVC
stream carries type-62 RPU NAL units, report the Dolby Vision profile read out of the RPU
header. ffprobe and dovi_tool both do this today. Reporting only the container means a
trimmed file silently loses a picture feature it still has, and the only way to find out is
to go looking at NAL types by hand.
If a full RPU parse is too much, even a note in the output that RPU NAL units are present
would be enough to stop somebody concluding the Dolby Vision was stripped.
Happy to supply whatever sample would help.
MediaInfo v25.04 (
MediaInfoLib - v25.04, Linux x86-64) reports no Dolby Vision at all ona file whose every frame carries a Dolby Vision RPU, when the Matroska container is missing
the
dvcCblock addition mapping.ffprobefinds the RPU on the first frame it looks at.I have 57 files in this state. They were all trimmed by a commercial tool that copies the
HEVC elementary stream but never writes the
dvcCandhvcEelements, so the picture datastill has Dolby Vision in it and nothing in the container says so. MediaInfo then names them
HDR10 or HDR10+, and I use MediaInfo output to name my files, so 57 of them got named wrong.
What MediaInfo says
No
Dolby Vision, no profile, nothing.What is actually in the first two frames
So this is a profile 7 stream: a Dolby Vision RPU and HDR10+ dynamic metadata in the
same elementary stream. MediaInfo reports the second and not the first.
The RPU is on every frame, not just the head. Counting NAL units over 20 seconds of one of
these files gives 483 type-62 (RPU) and 1133 type-63 (enhancement layer) units, one RPU per
frame — the same counts as the untrimmed source the file was cut from.
What separates a detected file from an undetected one
Only the container elements.
mkvinfoon a file MediaInfo does detect:On the undetected file both elements are absent. Same encoder, same profile, same RPU in
the bitstream.
The ask
Fall back to the bitstream when the container says nothing: if
dvcCis absent and the HEVCstream carries type-62 RPU NAL units, report the Dolby Vision profile read out of the RPU
header.
ffprobeanddovi_toolboth do this today. Reporting only the container means atrimmed file silently loses a picture feature it still has, and the only way to find out is
to go looking at NAL types by hand.
If a full RPU parse is too much, even a note in the output that RPU NAL units are present
would be enough to stop somebody concluding the Dolby Vision was stripped.
Happy to supply whatever sample would help.