dcpomatic/src/lib/writer.cc, branch bisectDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=bisect2024-05-11T19:00:37ZStop using video directory and hard-linking (#2756).2024-05-11T19:00:37ZCarl Hetheringtoncth@carlh.net2024-03-14T23:41:20Zurn: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.
Merge remote-tracking branch 'origin/main' into v2.17.x2024-05-07T23:53:50ZCarl Hetheringtoncth@carlh.net2024-05-07T23:53:50Zurn:sha1:6b2119dcd16c43fd681feace00d4e10f464bb9b7Work 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.
Support encoding of MPEG2 DCPs.2024-04-22T11:03:04ZCarl Hetheringtoncth@carlh.net2024-03-19T13:02:47Zurn:sha1:f72a79c93626e773214f1a0318adf2445ac2ee72Extract frame info read/write to new class.2024-04-21T21:18:23ZCarl Hetheringtoncth@carlh.net2024-03-26T21:43:10Zurn:sha1:f7518583f90a866a07d8069a78bebcea82b2b248Add dummy subtitle and closed caption reels even when referencing2024-01-04T22:36:08ZCarl Hetheringtoncth@carlh.net2024-01-03T23:40:03Zurn:sha1:23b0ff9c475265fb5309d20fe4094f5a96818d22
other DCPs (in a VF) that themselves might have missing subtitles
for some reels.
Improve progress reporting of digest calculations (might help with #2643).2023-11-20T06:29:15ZCarl Hetheringtoncth@carlh.net2023-11-12T21:09:48Zurn:sha1:db4fde2e8983eaa0b76c49a189e059d6c9f5720dFix 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
Use dcp::filesystem to wrap filesystem calls and fix_long_path2023-10-09T21:38:28ZCarl Hetheringtoncth@carlh.net2023-10-06T00:37:16Zurn:sha1:96f50dd5e600925488fdd9db1580aa01b026269b
anything that is passed to read_file() from libcxml.
This should fix #2623 and other similar problems.
Prevent empty <LabelText> in <ContentVersion> (#2594).2023-08-11T22:13:08ZCarl Hetheringtoncth@carlh.net2023-08-11T22:13:08Zurn:sha1:3472cd4dc301beb7db39419e922fc0b02cf36cf4