dcpomatic/src/lib, 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:a6a6d8a7a1c4c59bac9de6fa8f4cd879ebeef55dCleanup: sorting.2024-05-19T21:07:52ZCarl Hetheringtoncth@carlh.net2024-05-17T13:52:44Zurn:sha1:e9627c2ac61551e3598601805d12938479ad3dffEmit no audio from DCPs if none is mapped2024-05-17T13:03:15ZCarl Hetheringtoncth@carlh.net2024-05-17T13:03:15Zurn:sha1:7f6cc5c6e151c32fce94181689cf740a011feafb
This makes DCP content behave the same as FFmpeg.
Make sure we don't say some content has audio if none will be emitted.2024-05-17T13:02:57ZCarl Hetheringtoncth@carlh.net2024-05-17T13:02:57Zurn:sha1:afd18ea6b14373b2078b6d6dbc74c836e6843757
In the FFmpeg (and shortly DCP) case we don't emit any audio if none is mapped,
so we must take this into account in the player.
Update DCP encoder progress on all passe()es, not just when audio is emitted.2024-05-15T21:49:51ZCarl Hetheringtoncth@carlh.net2024-05-12T13:38:31Zurn:sha1:61130610f6d01fe6b1682d91933eb7dbbb1eac76Get DCP transcode progress from the player (#2804).2024-05-15T21:49:51ZCarl Hetheringtoncth@carlh.net2024-05-12T13:22:28Zurn:sha1:26678a922a1808db33954e002c165678d8191fc6Fix warning cause by previous libdcp bump.2024-05-13T22:02:54ZCarl Hetheringtoncth@carlh.net2024-05-13T22:02:54Zurn:sha1:bcf0f131281399f93fe2ca57c99d1046b3a2fb44Don't bother decoding audio if none of it is mapped (#2809).2024-05-13T21:03:04ZCarl Hetheringtoncth@carlh.net2024-05-12T23:20:27Zurn:sha1:e2ea739fcaa8077975a8559f267a1b1377b7e100
On a test adding subs from an MKV to an existing DCP this reduces
the processing time from ~2h to ~1m because it doesn't resample the
audio from the whole of the MKV, only to discard it.
Work 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:f5e08d6f36161a980682dd3cb9b0678d44adadfd