Estimated reading time: 4 minutes

 

Summary

This article explains how Dolby Vision CM 4.0 maintains compatibility with legacy CM 2.9 playback environments. It covers how compatibility metadata is generated, how to verify that the latest compatibility algorithm is in use, and what to do if older compatibility metadata is detected.

 

Who this is for

Colorists, mastering engineers, and QC specialists who need to verify Dolby Vision deliverables for compatibility with legacy Dolby Vision devices and workflows.

 

How CM 4.0 maintains compatibility with CM 2.9

When using the CM 4.0 Content Mapping algorithm, CM 2.9-compatible metadata is automatically generated and embedded within the Dolby Vision deliverable. This allows modern Dolby Vision content to remain compatible with legacy playback devices and workflows that rely on CM 2.9 processing.

For most deliveries, a separate CM 2.9 version doesn't need to be created. The CM 4.0 deliverable contains the information required for both CM 4.0 and CM 2.9 playback paths.

To support backward compatibility, CM 4.0 automatically creates trim metadata for the 1000 nit, 600 nit, and 100 nit CM 2.9 targets. Many Dolby Vision authoring applications allow these compatibility trims to be reviewed and refined if needed.

 

Verifying compatibility metadata

Modern Dolby Vision workflows generally include the latest compatibility algorithm. However, it's good practice to verify compatibility metadata when working with older projects, archived XML files, or unfamiliar workflows.

The easiest way to verify compatibility metadata is by validating the Dolby Vision XML using Metafier:

./metafier --validate <input_cm4.xml>

Locate the Level254 section in the validation output and review the CMVersion value. 

 

It is also possible to check the Level254 value by directly examining the XML. The example below shows the section of the XML file that covers the Level254 information.

 

For more details on examining XML files, see What's in the Dolby Vision XML file?

 

Understanding CM version values

The Level254 CMVersion value indicates which backward compatibility algorithm was used to generate the embedded CM 2.9 metadata.

Level 254	Compatibility state	Action
4 0	Uses the legacy CM 2.9 compatibility algorithm	Update before delivery
4 1	Uses the current CM 2.9 compatibility algorithm	No action required
4 2	Uses the current compatibility algorithm with artistically modified CM 2.9 trims	No action required

If you see 4 1 or 4 2, your compatibility metadata is current. If you see 4 0, update the CM 2.9 compatibility metadata before delivery.

 

Relationship between CM, XML and Level254 version numbers

The table below shows the relationship between CM, XML and Level254 version numbers. 

CM Version	'Algorithm Version' (XML version 2.0.5)	'Level 254' (XML version 4.0.2 and above)		Notes
2.9	2,0 | 2,1	n/a		current CMv2.9
2.9	2,1	n/a		CMv4.0 downgraded to CMv2.9 (using old backward compatible algorithm) - deprecated
2.9	2,2	n/a		CMv4.0 downgraded to CMv2.9 (using new backward compatible algorithm)
2.9	2,4	n/a		analyzed with CM algorithm version 4 (using cm_analyze)
2.9	2,5	n/a		CMv4.0 downgraded to CMv2.9 with artistically edited v2.9 metadata (L2)
4.0	n/a	4 0		Indicates old backwards backward compatible algorithm - deprecated
4.0	n/a	4 1		Indicates latest backwards backward compatible algorithm
4.0	n/a	4 2		Indicates artistically edited v2.9 metadata - no update required

 

 

Updating older compatibility metadata

If Level254 reports CMVersion 4 0, update the XML using Metafier version 5.0.1 or later:

./metafier --update-cm29-metadata <input_cm4.xml>

This generates a new XML containing the latest CM 2.9 compatibility metadata. The updated XML can then be used during mastering and delivery.

After updating:

1. Export the HDR master image sequence or file according to the delivery specification.
2. Use the updated XML during mastering.
3. Create the final IMF or deliverable package according to the delivery requirements.

 

Note: Run the update process only once. Running it multiple times can introduce minor metadata differences between versions and complicate QC comparisons.

 

SDR derivation

Backward compatibility metadata is intended for Dolby Vision playback compatibility and should not be used as the source for SDR mastering.

When creating SDR deliverables, always derive SDR from the original Dolby Vision master rather than from CM 2.9 metadata generated for compatibility purposes. This ensures the highest-quality SDR result.

 

Frequently asked questions

Do I need to create a separate CM 2.9 deliverable?

In most cases, no. CM 4.0 automatically embeds CM 2.9-compatible metadata, allowing a single CM 4.0 deliverable to support both modern and legacy Dolby Vision playback paths.

 

Can I convert a CM 2.9 project into CM 4.0?

No. A CM 2.9 XML cannot be automatically upgraded into a CM 4.0 project. To move from CM 2.9 to CM 4.0, return to the original grading system and rerun the Dolby Vision analysis and trim process using the CM 4.0 algorithm.

Note: Save a separate project version before switching algorithms. Existing analysis and trim data will be lost when changing CM algorithm versions.

 

Key takeaways

• CM 4.0 automatically generates CM 2.9-compatible metadata for legacy playback environments.
• A separate CM 2.9 deliverable is generally not required.
• Verify compatibility metadata by checking the Level254 CMVersion value.
• CMVersion 4 1 and 4 2 indicate current compatibility metadata.
• CMVersion 4 0 should be updated before delivery.
• Derive SDR from the original Dolby Vision master, not from compatibility-generated CM 2.9 metadata.
• CM 2.9 projects cannot be automatically converted into CM 4.0 projects.

 

If you have any questions about Dolby Vision backward compatibility, feel free to post them in our Dolby Vision Forum or share your findings with the Dolby Creators Community on Discord.