dcpomatic/run, branch v2.18.31DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=v2.18.312025-11-03T00:50:10ZMissing check for duplicate IDs.2025-11-03T00:50:10ZCarl Hetheringtoncth@carlh.net2025-11-03T00:10:39Zurn:sha1:b3056163b9da4425aab25e3c9630a805a48d30ff
Without this call we don't spot duplicates that are found in the initial
scan.
Add another new test reference for FFmpeg 8.2025-10-15T20:33:26ZCarl Hetheringtoncth@carlh.net2025-10-13T08:16:27Zurn:sha1:c6c883ae2e33f175682b9164c17fedb487a54ca4
Commit 045a8b15b19ec7f872fb01cfb986faeaa26cb8bb changed how AC3/EAC3
decoders in FFmpeg are flushed, and this caused a considerable change to
the audio result in this test (in particular, the audio is about 3db
louder after the FFmpeg change). I'm assuming the previous result was
just wrong.
Add --right-to-left option to run script.2025-09-27T20:41:38ZCarl Hetheringtoncth@carlh.net2025-09-27T20:39:54Zurn:sha1:6066d80cbc5a60ea1697466b5b21521be7db6197Return quite close to original approach for "no colour conversion".2025-09-23T07:14:10ZCarl Hetheringtoncth@carlh.net2025-09-19T09:41:03Zurn:sha1:aac6fad8adad9020e6a82140085091fdef2873cf
There's a few things going on here:
1. Improve the regression test for 3042. Previously we made a DCP from
the reporter's _original_ prores file (before they converted it to XYZ)
and compared the result to a reference J2K file of uncertain origin.
This seems wrong because:
a) We never got confirmation from the reporter that the fix worked for
them, so any arbitrary reference is dubious.
b) It doesn't seem to reflect their actual complaint, which was that
they got a different result when making a DCP from XYZ TIFFs compared
to their "XYZ" Prores.
The new test makes a DCP from their TIFFs and "XYZ" Prores and compares
the result.
2. Revert to the old approach to "no conversion" handling. In the good
old days we did everything -> RGB48LE except XYZ12LE -> XYZ12LE, and
that's what we do again here.
3. Change the YUV->RGB conversion from Rec.601 to Rec.709 for the
"no conversion" case. This fixes the 3042 regression test.
The supposed "XYZ" Prores is yuv444p12le according to ffprobe. So I
think what we have here is actually a file that was converted to XYZ
and then back to YUV by Resolve. I experimented with using the raw
YUV values and considering them as XYZ but this was clearly wrong.
I think 3 is probably what I should have done in the first place.
Make dcpomatic_create work when called from anywhere.2025-08-25T06:44:48ZCarl Hetheringtoncth@carlh.net2025-08-19T19:19:07Zurn:sha1:8394bbd8bb3e0bc7325bdf1db80e8705fa22db5dNew/improved pixel format decision when converting to XYZ.2025-08-12T15:16:07ZCarl Hetheringtoncth@carlh.net2025-07-21T22:48:42Zurn:sha1:98a8023dd774fd82c144a68039e0ea3131fb9142
For a long time we would keep XYZ12LE, if that's what we have, otherwise
ask FFmpeg to switch to RGB48LE.
Then in 1d5c211dadb9a9dc2318adce86ca9c31b367cabe I tried to fix the case
of an XYZ source mis-tagged as YUV. I changed things so that with no
colour conversion we'd always ask FFmpeg to convert to XYZ. This meant
that RGB sources with no colour conversion would get treatment by FFmpeg
due to the RGB -> XYZ switch.
Here we're going back to the more-or-less the "long time" behaviour when
there is a conversion (keep XYZ12LE but otherwise convert to RGB48).
When there's no conversion, keep RGB (to avoid the FFmpeg conversion
from RGB -> XYZ) but convert everything else to XYZ.
Fix incorrect colours with "no colourspace conversion" sources that are not AV_PIX_FMT_XYZ12LE.2025-05-26T19:51:18ZCarl Hetheringtoncth@carlh.net2025-05-22T23:23:43Zurn:sha1:1d5c211dadb9a9dc2318adce86ca9c31b367cabe
Prepare the image for where it is going to next. I don't understand the difference
in this situation between XYZ12LE and RGB48LE (it seems they are both 16-bit-per-channel)
but there you go.
Tidy up finding required files during tests.2025-05-19T19:25:35ZCarl Hetheringtoncth@carlh.net2025-05-18T20:20:02Zurn:sha1:8d18da108282203a90f4b5ae0123700b827e3eb7
In particular, prefer not to use lots of fallback attempts. It seems
that something funny is going on with how we find Liberation Sans on
Linux, meaning that we were sometimes using the OS copy of the font when
we didn't mean to.
Do leak checks when valgrinding the player.2025-04-13T19:06:41ZCarl Hetheringtoncth@carlh.net2025-04-13T19:06:41Zurn:sha1:c325ab5f745c67e6381bcee582bf809018d809e0Fix passing of parameters from create dev script.2025-03-22T12:29:59ZCarl Hetheringtoncth@carlh.net2025-03-21T11:39:50Zurn:sha1:d13d57f0bc12ba0d4c54cb106467fb0c9a5808e6