dcpomatic, branch v2.16.93 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.16.93 2024-09-17T09:05:49Z Supporters update. 2024-09-17T09:05:49Z Carl Hetherington cth@carlh.net 2024-09-17T09:05:49Z urn:sha1:ffa9430ad7519fb1b291af74f3bdae74cc26f453 Bump libdcp for increase in maximum allowable Interop XML file size. 2024-09-17T09:03:48Z Carl Hetherington cth@carlh.net 2024-09-17T09:03:48Z urn:sha1:8f4e2a0b5acb2cbadf2a134ab8cc8ce12cb66218 Bump maximum reel length. 2024-09-16T14:27:08Z Carl Hetherington cth@carlh.net 2024-09-16T14:27:08Z urn:sha1:9874ec134d667996b2952f13a70d1333b08fd693 Someone is making a very long (10h) DCP and wants big reels, and I can't think of a reason not to allow it. Some more distros that use wx-3.1. 2024-09-14T09:10:22Z Carl Hetherington cth@carlh.net 2024-09-14T09:10:22Z urn:sha1:b9d6fc2817c2dadec09d568792d294c21e2f8046 Bump libdcp for Windows build fix. 2024-09-14T09:08:04Z Carl Hetherington cth@carlh.net 2024-09-14T09:08:04Z urn:sha1:38460102945608b938729e8c8a1cd8d371adf5a1 Bump libdcp for Ubuntu 16.04 build fix. 2024-09-14T00:36:47Z Carl Hetherington cth@carlh.net 2024-09-14T00:36:47Z urn:sha1:eb6a28efc8c00b22ff93c6d4b434f624edbf8405 Fix Debian unstable build. 2024-09-14T00:05:14Z Carl Hetherington cth@carlh.net 2024-09-14T00:05:14Z urn:sha1:fc1c77b87b04188bec6056048f979e03659b4204 Bump libdcp for static boost fix in libcxml. 2024-09-14T00:01:26Z Carl Hetherington cth@carlh.net 2024-09-14T00:01:26Z urn:sha1:d83c9ffb117f1eb2a913ac3180a3a3f511a522bb Supporters update. 2024-09-13T21:34:11Z Carl Hetherington cth@carlh.net 2024-09-13T21:34:11Z urn:sha1:4f850f9958beacd8d2b39fda1941b68ffb94b2f0 Hopefully fix occasional hang in j2k_encoder_deadlock_test. 2024-09-12T23:14:21Z Carl Hetherington cth@carlh.net 2024-09-12T22:56:17Z urn:sha1:f02501491e262c52b65c3fea6e180814e132dad8 Previously too many frames were queued for encoding, which AFAICS meant that (if the CPU was busy) we would get to the point where too many frames were in the encoder queue, so that we blocked waiting for it to clear, and then simultaneously too many frames were in the writer queue, which (in this test) would never clear. At this point we would be backed up waiting for Writer::write() to happen in J2KEncoder::encoder_thread() so that the encoder queue could be cleared, but nobody is calling Writer::write().