Feature Request: Dolby Vision Content Mapping Version (CMV) Detection

[infomaniac777]

Problem:
MediaInfo currently reports Dolby Vision metadata (profile, level, layers) but not the Content Mapping Version (CMV), which identifies the mapping standard (v4.0 or v2.9).

Proposed Solution:

• Extract CMV from Dolby Vision streams using external tools (dovi_tool + ffmpeg)
• Add a new field Video_HDR_Format_CMV to expose the raw CMV value
• Display CMV in the HDR format line when known (CM v4.0 or CM v2.9) for clarity
• Use optimized single-frame extraction to minimize performance impact

Implementation Approach:

• Use dovi_tool to extract RPU data and ffmpeg for efficient frame extraction
• Only activate when MEDIAINFO_ADVANCED is enabled and external tools are available
• Gracefully degrade if tools are missing (no error, simply no CMV data)

Is this feature direction acceptable? If so, I can prepare a PR with the implementation. If you suggest a different approach, I can adjust.

[cjee21]

Just need to modify #2392. No external tools needed.

[JeromeMartinez]

Use dovi_tool to extract RPU data and ffmpeg for efficient frame extraction

FFmpeg plugin is for when we need to decode content (we don't want to implement a full decoder in MediaInfo), and if I understand well the need, here it is bitstream parsing (no need to decode) so it should be directly in MediaInfo. #2392 is pending my review (sorry @cjee21 for the delay) and it seems to be enough for peeking the CMV value, doesn't it? Do you know where in the bitstream is the value you are wanting to peek?

[cjee21]

Do you know where in the bitstream is the value you are wanting to peek?

Value is not directly in bitstream. I have already added comments for CMv in the PR. Just need to modify to add a field for it in the struct.

[JeromeMartinez]

I have already added comments for CMv in the PR.

Thank you, I'll check that.

[infomaniac777]

#2392 seems to be a better implementation to solve this problem. So I'll pause any implementation for this at my end. Assuming @cjee21 intends to complete the CMV part as well. Thanks !

[Lang45]

你知道你想查看的值在比特流中的哪个位置吗？

值并非直接存在于比特流中。我已经在 PR 中添加了 CMv 的注释。只需要修改结构体，为其添加一个字段即可。

In the Dolby Vision RPU structure, the Content Mapping (CM) Version is not stored as a direct string (e.g., "2.9" or "4.0"). Instead, it must be inferred from the Metadata Block Levels present in the vdr_dm_data.
Differentiation Logic:
CM v2.9 (Legacy)
Definition: Contains only the basic metadata blocks: Level 1, 2, 5, and 6.
Reference: In dovi_tool JSON output, these are grouped under cmv29_metadata.
CM v4.0 (Advanced)
Definition: Extends v2.9 by including advanced metadata blocks: Level 3, 8, 9, 11, and 254.
Reference: In dovi_tool JSON output, these appear under cmv40_metadata.
Key Identifier: Level 254 is specifically designated as the "DM Version Index". The presence of Level 254 (or Levels 8/9/11) is the definitive sign of a CM v4.0 RPU.

Please parse the vdr_dm_data payload in the RPU to differentiate between CM v2.9 and CM v4.0.
Detection Logic:
The distinction lies in the presence of specific Extension Metadata Blocks within the RPU:
CM v4.0: Defined by the presence of Level 254 (DM Version Index), Level 8 (Trim), Level 9 (Source Primaries), or Level 11 (Content Type).
Logic: If vdr_dm_data contains an extension block with ext_block_level == 8, 9, 11, or 254 -> Report "CM v4.0".
CM v2.9: Defined by the presence of only legacy blocks (Level 1, 2, 5, 6).
Logic: If vdr_dm_data exists but contains NO blocks > Level 6 -> Report "CM v2.9".

[cjee21]

Detection Logic:
The distinction lies in the presence of specific Extension Metadata Blocks within the RPU

It's already implemented in RPU parsing PR in November. Detection is by presence of second num_ext_blocks added in CMv4.0 and not by checking presence of individual ext_block_level.