DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=xmlsec-debug 2024-09-13T21:43:12Z 2024-09-13T21:43:12Z Carl Hetherington cth@carlh.net 2024-09-13T21:43:12Z urn:sha1:c1d3f6f4f645e76302ca4262de3517497fa1e14b 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(). 2024-05-22T08:33:45Z Carl Hetherington cth@carlh.net 2024-05-20T14:55:57Z urn:sha1:c95ba3eb99c5e4d6dca90cee7e5bb9077b6ed02c 2024-05-11T19:00:37Z Carl Hetherington cth@carlh.net 2024-03-14T23:41:20Z urn:sha1:d2c665cba983c625933817e0bf05e298f80f0119 Instead store details of a previously-created asset in the film's metadata and then look there for potential video files to re-use. 2024-05-08T06:52:02Z Carl Hetherington cth@carlh.net 2024-05-08T06:52:02Z urn:sha1:b83321a4e3065ca90bed7e329c77ef8f35c3036d 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.