dcpomatic/test, branch v2.18.25DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=v2.18.252025-09-23T07:14:10ZReturn 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.
Rename check_one_frame -> check_one_frame_against_j2c2025-09-22T09:42:52ZCarl Hetheringtoncth@carlh.net2025-09-18T10:44:16Zurn:sha1:a757fe63424074e9d3dfe7847a17bfe2b5fd93deAllow building with boost::process v2 (added in Ubuntu 25.10).2025-09-15T12:27:21ZCarl Hetheringtoncth@carlh.net2025-09-14T20:16:01Zurn:sha1:7cd1d82e33d074050b132dba8c4ae4e0d4804310Add audio delay option to Config and player prefs.2025-09-07T18:04:44ZCarl Hetheringtoncth@carlh.net2025-09-05T22:45:44Zurn:sha1:0eadbd860d04cc2322d18046f69e7a9b2cb437f4Fix incorrectly-clipped audio on export (possibly #2865).2025-09-06T15:15:46ZCarl Hetheringtoncth@carlh.net2025-09-06T15:15:46Zurn:sha1:24052ed1b36e0ce81fb863830a93f8282285f30dAdd cover sheet magic strings for marker positions (#3076).2025-08-25T09:22:27ZCarl Hetheringtoncth@carlh.net2025-08-22T21:50:28Zurn:sha1:6ea9b75c5fc4736f19a424796a3d2c7550fb16dcUse 0-padded numbers for all fields of a timecode.2025-08-25T09:22:27ZCarl Hetheringtoncth@carlh.net2025-08-22T21:37:39Zurn:sha1:3b9402e620a83d8d23d9df334c4c40fa091c0b6fWhite space: util_test.cc.2025-08-25T06:47:42ZCarl Hetheringtoncth@carlh.net2025-08-22T20:18:16Zurn:sha1:f6ff08b405cf0adbe548a52851761183658a419dNew/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.
Replace AVPixelFormat parameter to PlayerVideo::image with a functor.2025-08-12T15:16:07ZCarl Hetheringtoncth@carlh.net2025-07-21T22:18:32Zurn:sha1:9b73c143ce568bd8694e3a50f2fefc1ee3a03515
This was removed in df9b4676aba8b941f124b174393988cad21677e1 and
surrounding commits, but it turns out we need it after all.