dcpomatic/src/lib/writer.h, branch fread-loggingDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=fread-logging2024-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.
Add some missing includes.2024-05-07T23:33:28ZCarl Hetheringtoncth@carlh.net2024-05-05T19:34:22Zurn:sha1:f5e08d6f36161a980682dd3cb9b0678d44adadfdImprove progress reporting of digest calculations (might help with #2643).2023-11-20T06:29:15ZCarl Hetheringtoncth@carlh.net2023-11-12T21:09:48Zurn:sha1:db4fde2e8983eaa0b76c49a189e059d6c9f5720dMore header trimming.2022-12-13T10:18:31ZCarl Hetheringtoncth@carlh.net2022-12-13T10:18:31Zurn:sha1:0185ba27b0e9c52a173147c1380ec5f345109afcRemove some unnecessary use of shared_ptr.2022-10-16T22:10:59ZCarl Hetheringtoncth@carlh.net2022-10-14T19:21:36Zurn:sha1:bfd6bd32b5e20c479170452a66cb44eff59feacdRearrange subtitle font management.2022-06-07T15:01:06ZCarl Hetheringtoncth@carlh.net2022-06-01T11:03:38Zurn:sha1:5a820bb8fae34591be5ac6d19a73461b9dab532a
With this change each subtitle coming out of the player has a reference
to a dcpomatic::Font that belongs to the TextContent. This hopefully
solves a few problems which all basically stemmed from the fact that
previously the decoders/player were deciding what the font ID in the
output DCP would be - they can't do that properly.
Rearrange some includes of dcpomatic_time.h2022-06-07T15:01:06ZCarl Hetheringtoncth@carlh.net2022-06-01T09:05:53Zurn:sha1:3ee25c2fabd43040f9388efa89482b90cb4ccadcTidying.2022-06-07T15:01:06ZCarl Hetheringtoncth@carlh.net2022-06-01T09:02:09Zurn:sha1:b76970eee97ab03741e4c0e1fb30b75f7991ef70C++11 tidying.2021-04-30T23:31:35ZCarl Hetheringtoncth@carlh.net2021-04-30T23:31:35Zurn:sha1:8963f0007af1a312017b9627c18b82ec2a577591Move digest calculation to a separate method.2021-04-20T22:52:07ZCarl Hetheringtoncth@carlh.net2021-04-20T17:52:44Zurn:sha1:e4b693f2e7b7dc2afb4e9ec3e96e317fff851c5b