DCP-o-matic

Download it now from here.

This is the first beta release of what will become the new stable version 2.18.0 of DCP-o-matic, which includes everything in 2.16.91 and adds some new features and fixes.

You are advised to use this version only for testing, not in production systems.


This version will convert the XML files containing your cinema, screen and DKDM recipients to SQLite3 format (leaving the old XML files behind). If you change any of these details the changes will not be visible to older DCP-o-matic versions. It is a good idea to back up your cinema and DKDM recipients files (if you use those features) before installing this version.


Full list of changes

• DCP-o-matic now takes video frame timing information from sources in a (hopefully) more reliable way, which should fix video/audio sync errors in a number of cases.
• Support has been added for a commercial (paid-for) GPU-based JPEG2000 encoder (‘Grok’) that provides dramatic encoding speed-ups with Nvidia graphics cards on Ubuntu 22.04.
• Cinema and DKDM recipient information is now stored using SQLite (rather than XML), meaning that use of shared cinema database files should be more reliable.
• There is now experimental support for playback and creation of MPEG2 DCPs.
• The user interface for making VFs has changed. You can now set them up using a separate dialogue box, which can be opened with the ‘Version File (VF)...’ option in the ‘Tools’ menu.
• A new user interface for setting up reels has been added, which allows setup of custom reel breaks.
• UTC offset for KDMs is specified when KDMs are created, not when setting up the ‘Cinema’. This is to avoid difficulties when cinemas are in places where timezones change through the year (e.g. where there is daylight saving time).
• There is now support for open captions and closed subtitles.
• A separate DCP verification tool is included.
• Add option to copy content settings from another project.
• Template features have been improved, and some default settings removed in favour of using a template.
• A menu option was added to un-map all audio channels for a piece of content.
• It is now possible to save projects with relative (rather than absolute) content paths.
• DCP-o-matic can make text or HTML reports during verification runs.
• DCP-o-matic is now linked against openjpeg 2.5.2. This provides some worthwhile speed-ups compared to the previous version.
• DCP-o-matic is now linked against FFmpeg 7.0.1.
• The audio language settings has been moved to the DCP audio tab.
• On loading a project DCP-o-matic will show the DCP panel if that was what was open when the project was last edited.
• Some XML attribute names were reformatted to ‘camel-case’.
• Fix some errors related to font IDs.
• Fix rendering of subtitles where there are colour changes within a line.
• Add ProRes LT export option.
• Add basic HTTP interface to control the player.

>A separate DCP verification tool is included.

Is this different from the verification option in DCP-o-matic player?

Not really, it uses the same code to check the DCP - it's just a new "front-end" I suppose.

Wouldn't it have to be a separate download then (for Mac)? Because I don't find it in the Mac OS download options.


I'm currently verifying a few DCPs I backed up - I notice the player 2.17.20 verification now seems to check hashes first - is that konsistent/intentional? I always wanted to have an option to hash-check-only DCPs I created myself (as in DCP-o-matic player prior to 2.16), or commercial DCPs that I assume to have proper code-stream properties and be formally correct (the code stream checks take very long).

If it hash-checks first now, I may just cancel verification after the hash checks?

edit: No, seems that DCP-o-matic player still mixes hash checking and picture frame size checking.

Maybe we could have two options for verification - 'Integrity' (hash checks and completeness), and 'Verification' or ''Validation'?


Or, since the verification code has to read through the files for both hash-checks and codestream compliance - couldn't it perform both checks during one read?

- Carsten

I missed it off the website for mac/Appimage - I just added it.

Did we already file the verification vs. validation somewhere in the bug tracker? It makes sense to me.

Perhaps the hash checks and code-stream stuff could be merged, indeed.

carl wrote: Mon Sep 16, 2024 3:23 pm
Did we already file the verification vs. validation somewhere in the bug tracker? It makes sense to me.

Perhaps the hash checks and code-stream stuff could be merged, indeed.

Hmm, yes, I filed it a while back...


There it is: https://dcpomatic.com/mantis/view.php?id=2656

I think hashing in DCP-o-matic main after conversion is multithreaded/per reel, but in player, it seems to be single-thread? On machines with internal SSDs like the latest Macs with internal flash, performing the checks multithreaded should be very very fast?

You're right, yes, the verifier hashing is single-threaded but the DCP creation hashing is multi-threaded.