dcpomatic/test/wscript, branch smpte-aDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=smpte-a2024-05-19T21:07:52ZGeneralise SMPTE Bv2.0 limitation to also support SMPTE A.2024-05-19T21:07:52ZCarl Hetheringtoncth@carlh.net2024-05-17T13:52:39Zurn:sha1:a6a6d8a7a1c4c59bac9de6fa8f4cd879ebeef55dWork 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 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:befbada161a66a16f8ced89773ad11c0ac5c91e5Re-make video after YUV/RGB matrix is changed (#2714).2024-01-09T12:02:09ZCarl Hetheringtoncth@carlh.net2024-01-09T12:02:09Zurn:sha1:c2c6fbdd8dddbb6ccba0a6ae49a13d5364122df7Move ScopeGuard into libdcp.2024-01-09T10:54:16ZCarl Hetheringtoncth@carlh.net2024-01-08T15:25:42Zurn:sha1:12d1abf033654727d6ab6278087ff7cfc65d63f6Remove unused code.2023-10-16T09:30:27ZCarl Hetheringtoncth@carlh.net2023-10-16T09:30:27Zurn:sha1:4b8f2b64ebb7fcba20c3c03d7bccd08e48612fbbFix DCP content font ID allocation to cope with DCPs that have multiple fonts2023-10-15T07:10:18ZCarl Hetheringtoncth@carlh.net2023-10-14T19:48:25Zurn:sha1:3c802dd6d1451c2c8a7e188f8379738d72e907eb
with the same name in the same reel (#2600).
Previously we had this id_for_font_in_reel() which would give an ID
of N_font-ID. This means we got duplicate font IDs.
Here we replace that method with FontAllocator, which gives an ID of
N_font-ID for the first font and M_font-ID, where M is a number higher than
the highest reel index. The idea is to support the required new IDs
without breaking exisiting projects.
There is some documentation of how it works in doc/design/fonts
Restore burnt subtitle tests.2023-08-29T16:29:58ZCarl Hetheringtoncth@carlh.net2023-08-26T17:49:25Zurn:sha1:54b2c8580ee0553fbfb88e8881af60e3afa2e2fdAdd some tests.2023-08-09T08:18:46ZCarl Hetheringtoncth@carlh.net2023-08-08T21:53:42Zurn:sha1:fc329637dd1e35e8cde6d82f3131050b578b07cf