dcpomatic/src/lib/j2k_encoder.cc, branch bisect DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=bisect 2024-05-07T23:53:50Z Merge remote-tracking branch 'origin/main' into v2.17.x 2024-05-07T23:53:50Z Carl Hetherington cth@carlh.net 2024-05-07T23:53:50Z urn:sha1:6b2119dcd16c43fd681feace00d4e10f464bb9b7 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. Allow specification of video bit rate separately for J2K and MPEG2. 2024-04-22T11:03:04Z Carl Hetherington cth@carlh.net 2024-04-05T21:17:03Z urn:sha1:21ebc2365dd7a66c05d130dc87861f7399ae834b Rename j2k_bandwidth -> video_bit_rate. 2024-04-21T21:18:23Z Carl Hetherington cth@carlh.net 2024-04-05T19:57:03Z urn:sha1:c98d6fd22da1586ef3c1d64a2f7b1ee602f539e9 Extract VideoEncoder as a parent of J2KEncoder. 2024-04-21T21:18:23Z Carl Hetherington cth@carlh.net 2024-03-19T16:10:27Z urn:sha1:fa15dc1a375e13d2047a857e5aef202179eec0d4 Swap a log for a more informative one. 2024-01-28T01:01:58Z Carl Hetherington cth@carlh.net 2023-10-18T20:59:19Z urn:sha1:af49ed317148be178e8adfe131c443ce701f01f2 Clean up grok's presence in the config file and make sure it's optional. 2024-01-28T01:01:58Z Carl Hetherington cth@carlh.net 2023-10-06T20:42:44Z urn:sha1:1760066150070717bf8954313550afdd25a0f3fe It should be allowed to not have any grok stuff in the config file, and we should generally call it grok rather than GPU in case other non-grok GPU stuff arrives in the future. Another patch from Aaron. 2024-01-28T01:01:57Z Carl Hetherington cth@carlh.net 2023-10-04T17:11:45Z urn:sha1:d76a96b6c92f708162eaa542f316fe6247410967 Forward-declare grk_plugin stuff. 2024-01-28T01:01:57Z Carl Hetherington cth@carlh.net 2023-09-26T11:32:00Z urn:sha1:ce1c39e267c2bca215861d1ccc3e68ab1359ce30 Create a single DcpomaticContext for all GrokContexts, rather than copying them. 2024-01-28T01:01:57Z Carl Hetherington cth@carlh.net 2023-09-26T11:29:59Z urn:sha1:e55d917a7e3a0d2988c3f53c3027fe890970e6a8 I think this makes sense, and also allows us to forward-declare the contexts in a forthcoming commit.