dcpomatic/test, branch v2.16.83DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=v2.16.832024-05-07T23:33:41ZWork around deadlock when destroying J2KEncoder with a full writer queue (#2784).2024-05-07T23:33:41ZCarl Hetheringtoncth@carlh.net2024-05-05T19:34:29Zurn: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.
Fix hanging/overlapping dvb subtitles (#2792).2024-03-31T23:04:43ZCarl Hetheringtoncth@carlh.net2024-03-31T23:04:41Zurn:sha1:94618a724124cbf5fe9f0b47a3fdce601fcd5581
This reverts a change made in
8ca6fd6d97e6d42492afddb655fa85130946853c
"Fix doubled subtitles if subtitle stop times are specified."
That change breaks the case where a subtitle _does_ have a stop time,
but it's wrong (30s from the start time) and we want the next subtitle
to clear the previous one.
I can't now see how reverting this could cause doubled subtitles,
so maybe that problem wlil come back. At least now there's a test
for #2792.
Fix failing tests.2024-03-20T06:41:24ZCarl Hetheringtoncth@carlh.net2024-03-11T14:25:16Zurn:sha1:026f7e95210cafb6b44a1c207041df085ce92d95
Broken in the fix for #2780, when we started to check that referenced
audio MXFs have the correct number of channels.
Fix screen name order in KDM emails.2024-03-07T22:33:03ZCarl Hetheringtoncth@carlh.net2024-03-07T22:33:03Zurn:sha1:04b5957318df591f56e0a5d39720df143dc8230dMake DCPExaminer::size() optional and deal with the consequences.2024-02-21T17:48:53ZCarl Hetheringtoncth@carlh.net2024-02-21T09:47:38Zurn:sha1:3ffd0163026be24e5373e0674c3301ed37546e44
This means we can fix the case of a VF having no known size in a nice way,
in turn fixing problems caused by the fix to #2775.
Fix failure to examine non-flat-ratio VFs (#2775).2024-02-21T00:27:31ZCarl Hetheringtoncth@carlh.net2024-02-21T00:10:23Zurn:sha1:a9b1c1cb65e1902a64430977cf698054e131a6f4Add Unzipper.2024-02-16T22:37:59ZCarl Hetheringtoncth@carlh.net2024-02-15T00:05:12Zurn:sha1:befbada161a66a16f8ced89773ad11c0ac5c91e5Don't add a font with an empty ID for ccaps either (#2762).2024-02-11T22:31:39ZCarl Hetheringtoncth@carlh.net2024-02-11T19:13:04Zurn:sha1:eb04ac87ccfa046dd342ca7b9e6478c3bdcabbba
Previously this was all changed so that for subs we add the default
font in a cleaner way (in db22f81ccce9e1a5f205e6d8b3c0631fc039a173).
I can't see why we shouldn't treat ccaps the same way, and indeed
not doing it causes an error as shown by the included test.
Fix apparently ineffective processors when analysing audio (#2671).2024-02-11T21:55:27ZCarl Hetheringtoncth@carlh.net2024-02-11T12:10:48Zurn:sha1:527093fa643049d370f4daee8206349981edbf95
A whole film ("DCP side") analysis would behave the same as a
single piece of content analysis if the film only had one piece
of content.
Here we also clarify that audio analysis of the whole film is different
to that for a single piece of content; for the whole film we use processors,
and for single pieces of content we do not.
Remove apparently out-of-date comment.2024-02-06T23:21:44ZCarl Hetheringtoncth@carlh.net2024-02-06T10:07:53Zurn:sha1:fbcfa342d9f8d6f1430065ad18a1a1b8f7b925db