dcpomatic/src, branch v2.16.84 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.16.84 2024-05-16T07:26:00Z Supporters update. 2024-05-16T07:26:00Z Carl Hetherington cth@carlh.net 2024-05-16T07:26:00Z urn:sha1:7a9cadc6fe86c74035dd971685b1acdc8f32d3fc Update DCP encoder progress on all passe()es, not just when audio is emitted. 2024-05-15T21:49:51Z Carl Hetherington cth@carlh.net 2024-05-12T13:38:31Z urn:sha1:61130610f6d01fe6b1682d91933eb7dbbb1eac76 Get DCP transcode progress from the player (#2804). 2024-05-15T21:49:51Z Carl Hetherington cth@carlh.net 2024-05-12T13:22:28Z urn:sha1:26678a922a1808db33954e002c165678d8191fc6 Fix warning cause by previous libdcp bump. 2024-05-13T22:02:54Z Carl Hetherington cth@carlh.net 2024-05-13T22:02:54Z urn:sha1:bcf0f131281399f93fe2ca57c99d1046b3a2fb44 Don't bother decoding audio if none of it is mapped (#2809). 2024-05-13T21:03:04Z Carl Hetherington cth@carlh.net 2024-05-12T23:20:27Z urn:sha1:e2ea739fcaa8077975a8559f267a1b1377b7e100 On a test adding subs from an MKV to an existing DCP this reduces the processing time from ~2h to ~1m because it doesn't resample the audio from the whole of the MKV, only to discard it. Fix link icon width again. 2024-05-11T08:57:01Z Carl Hetherington cth@carlh.net 2024-05-11T08:57:01Z urn:sha1:63fd3d143387bc0dbbbe228955421a59239dbe5c Seems to be different on wxWidgets 3.1.x vs 3.2.x. Work around deadlock when destroying J2KEncoder with a full writer queue (#2784). 2024-05-07T23:33:41Z Carl Hetherington cth@carlh.net 2024-05-05T19:34:29Z urn:sha1:32d04ddb5c583938f470ed74bda8a50cc2ec9960 This feels like a hack, but I can't think of a nicer way to do it. The interruption disable makes sense because when we destroy encoder threads during a DCP encode (because a remote server goes away, for example) we don't want any frames to be lost due to the encode thread being interrupted between taking the frame off the queue and sending it to the writer. When we're destroying the encoder we don't care about this, but I can't see how you'd differentiate. Maybe the encoder queue could have two lists: to-do and in-progress; the encoder thread atomically moves a frame from to-do to in-progress, but then how do you know when the in-progress ones are orphaned and need to be re-added to the main queue. You could make the writer return saying "no" if the queue is full (rather than blocking and waiting for the queue to empty) but that seems wasteful as then the frame would be re-encoded. Add some missing includes. 2024-05-07T23:33:28Z Carl Hetherington cth@carlh.net 2024-05-05T19:34:22Z urn:sha1:f5e08d6f36161a980682dd3cb9b0678d44adadfd Supporters update. 2024-05-07T22:33:13Z Carl Hetherington cth@carlh.net 2024-05-07T22:33:13Z urn:sha1:4541d4d553b5903b63753f22254a6471c73337da Remove in-place translations support. 2024-05-03T22:19:02Z Carl Hetherington cth@carlh.net 2024-05-03T22:19:00Z urn:sha1:f8a0f78aaeb113cbf952d48b8d61bffc8bd2ee6d It feels like there have been too many failed attempts and not enough (maybe zero?) successes so it's just too confusing.