dcpomatic/test/client_server_test.cc, branch v2.11.78 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.11.78 2018-02-24T23:34:36Z Speed some operations by re-using the last PlayerVideo but with 2018-02-24T23:34:36Z Carl Hetherington cth@carlh.net 2018-02-24T01:05:14Z urn:sha1:d08123f5e160b5737fa912cd36119e810abaa4cd updated metadata (where possible). Helps with #1194. Fix incorrect pixel format on subtitles when they are sent to encoding servers. 2018-02-02T17:23:25Z Carl Hetherington cth@carlh.net 2018-02-02T17:23:25Z urn:sha1:496d364e2b8eaba0e9bd89b70660e58bbd9a1f29 Fix client_server_tests on Docker. 2017-10-16T21:26:38Z Carl Hetherington cth@carlh.net 2017-10-16T21:26:38Z urn:sha1:62224943d3d3f2f2e5df285b35a0d3c3341ad247 Fix required test. 2017-07-28T15:24:09Z Carl Hetherington cth@carlh.net 2017-07-28T15:24:09Z urn:sha1:96f701cab4f397272b84200bc75bc6421d364e5b Fix another hang in tests. 2017-05-29T23:33:08Z Carl Hetherington cth@carlh.net 2017-05-29T23:33:08Z urn:sha1:6ef3186a7d8288f668185af04946ef42f0cb3fce Fix hang in client_server tests. 2017-05-29T22:04:44Z Carl Hetherington cth@carlh.net 2017-05-29T22:04:44Z urn:sha1:8b183eea3238cc2f25cf62e63d724a2d2d361ee7 Fix leaked threads in client-server test. 2017-05-26T23:00:29Z Carl Hetherington cth@carlh.net 2017-05-26T23:00:29Z urn:sha1:676751fcd38bee7a687bba027e2fd6eb44446dec Various Doxygen fixes. 2017-04-19T22:04:32Z Carl Hetherington cth@carlh.net 2017-03-02T15:37:13Z urn:sha1:67a68bd971ebe1b35daa3f75873b4ccb53c00ba0 Attempt to tidy up internal APIs slightly. 2017-04-19T22:04:32Z Carl Hetherington cth@carlh.net 2016-11-28T23:45:34Z urn:sha1:a78b741c43830c84bcb4d18e3147746f13a668e5 Fix handling of incorrectly-recognised JPEG2000 files. 2016-06-29T15:01:14Z Carl Hetherington cth@carlh.net 2016-06-29T15:01:14Z urn:sha1:92c691f29c5da9abca6a06605998e09f9b8103bb Previously we asked libdcp whether an imported J2K file was RGB or XYZ. The answer it gives is sometimes wrong, for reasons that are not clear (either the files are not marked correctly, or openjpeg is not parsing whatever metadata correctly). However it seems that, in general, we use the user's specified colour conversion to decide what to do with an image, rather than asking the image what should be done to it. Hence it makes more sense to assume that if a user specifies no colour conversion for a J2K file then the file is XYZ. With preview, the colour conversion from XYZ back to RGB is done by FFmpeg, so we have to set the pixel format correctly on the Image that comes back from J2KImageProxy. Now we get that pixel format from the configured colourspace conversion rather than from openjpeg's guess as to the file's colourspace. It's a bit ugly that the only thing we ask the file about is whether or not it is in YUV (which governs whether or not FFmpeg applies the user's configured YUV-to-RGB conversion). Everything else is decided by the configured conversion. I think there's still some uglyness in here that I can't put my finger on.