dcpomatic/src, branch support-080626 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=support-080626 2026-05-08T12:30:21Z Debug logging. 2026-05-08T12:30:21Z Carl Hetherington cth@carlh.net 2026-05-08T10:20:16Z urn:sha1:8af5fd39e434957b0e10e07341f1ced120a49568 Protect _dcp_decode_reduction with the mutex rather than a std::atomic. 2026-05-07T12:45:09Z Carl Hetherington cth@carlh.net 2026-05-07T12:45:09Z urn:sha1:6f25d2a23ea2bc891c75a95389ed41ee17332880 Things in boost/std::atomic must be trivially copiable. Use std::atomic rather than boost::atomic. 2026-05-07T12:35:30Z Carl Hetherington cth@carlh.net 2026-05-07T12:35:30Z urn:sha1:4aef8dd81aeb7698aae314c5fe8fc35016d3502b It's in C++11. Add --trusted-device-chain option to KDM CLI. 2026-04-26T20:39:27Z Carl Hetherington cth@carlh.net 2026-04-26T20:39:24Z urn:sha1:81b15e9e131094879b416b26601c673e6ae0d508 Warn if you specify trusted devices with a formulation that won't use them. 2026-04-26T20:39:12Z Carl Hetherington cth@carlh.net 2026-04-26T20:39:12Z urn:sha1:25ac279e5b7ae6593185230a0fe5a4022a6f689d Supporters update. 2026-04-24T10:36:15Z Carl Hetherington cth@carlh.net 2026-04-24T10:36:15Z urn:sha1:72d4e2249dc6af0a31f04ff412a7eae84ac3cc4f Fix 32-bit Windows build. 2026-04-23T15:22:39Z Carl Hetherington cth@carlh.net 2026-04-23T15:02:31Z urn:sha1:d71b711220d77cd77b52bcf8316f01c09280537a Supporters update. 2026-04-23T14:54:38Z Carl Hetherington cth@carlh.net 2026-04-23T14:54:38Z urn:sha1:382cb18785d0e4c284d3ee67fe3946bd77b23f0e Fix reading of RGB0 images. 2026-04-23T14:51:08Z Carl Hetherington cth@carlh.net 2026-04-22T20:24:09Z urn:sha1:e54f93bf7d144737df4b0331017164360c9121ff We would allocate 3 bytes per pixel instead of 4. I couldn't see a way to get FFmpeg to tell us about this (unless we used FFmpeg's stride somehow maybe?) Fix late subtitles when they are muxed late with respect to the video. 2026-04-23T14:49:48Z Carl Hetherington cth@carlh.net 2026-04-18T11:39:33Z urn:sha1:9f828b327e680c322a70883910233337a37e481e In one example we have the sequence video 3088,377 sub 3087,334 sub 3088,710 video 3088,419 so the 3087,334 sub is very late. Here we insert a queue to bring subtitle packets a little forward for processing. There is already a similar thing in the player (_delay) but adding a longer delay there seems wasteful because a) the video is by that point already decompressed and b) this problem only applies to FFmpeg-decoded files (and then, I think only if we are previewing or burning in subtitles).