dcpomatic/src/lib/writer.h, branch mainDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=main2025-08-25T06:47:42ZMove write_cover_sheet() out to its own file.2025-08-25T06:47:42ZCarl Hetheringtoncth@carlh.net2025-08-22T19:50:00Zurn:sha1:99a191c599724ee8bab43146f9ea5da388c10225White space: writer.{cc,h}2025-08-22T19:35:44ZCarl Hetheringtoncth@carlh.net2025-08-22T19:35:44Zurn:sha1:61c74126cde9592587d31b4acbc54dd6c76a44d3Give ownership of info files to ReelWriters (#2912).2024-12-26T16:20:25ZCarl Hetheringtoncth@carlh.net2024-12-16T00:58:57Zurn:sha1:24728b74693bb84d79474e014cdb952abc8a79f2
The motivation here is to stop a pattern where we create a file, close
it, and then re-open it (many times) as I think there are problems on
Windows when a virus scanner sees the new file, opens it for checking,
and then we can't re-open it.
This also makes things a fair bit simpler, as a lock is removed and we
don't try to differentiate read/write cases by opening the file in
different ways; it's now always writeable.
Stop 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.
Add some missing includes.2024-05-07T23:33:28ZCarl Hetheringtoncth@carlh.net2024-05-05T19:34:22Zurn:sha1:f5e08d6f36161a980682dd3cb9b0678d44adadfdSupport encoding of MPEG2 DCPs.2024-04-22T11:03:04ZCarl Hetheringtoncth@carlh.net2024-03-19T13:02:47Zurn:sha1:f72a79c93626e773214f1a0318adf2445ac2ee72Only build grok for Ubuntu 22.04.2024-01-28T01:01:57ZCarl Hetheringtoncth@carlh.net2023-09-24T10:09:16Zurn:sha1:a72355666ed6abbd02bc6b124fddd24f598f89deImprove progress reporting of digest calculations (might help with #2643).2023-11-20T06:29:15ZCarl Hetheringtoncth@carlh.net2023-11-12T21:09:48Zurn:sha1:db4fde2e8983eaa0b76c49a189e059d6c9f5720d