dcpomatic/src/lib/dcp_decoder.cc, branch v2.9.28 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.9.28 2016-08-26T08:21:54Z Fix failure to display when loading old films with imported DCPs. 2016-08-26T08:21:54Z Carl Hetherington cth@carlh.net 2016-08-26T08:21:54Z urn:sha1:a6f586564a8f596ab101639298633933a05c0d60 Allow import of OV/VF DCPs (#906). 2016-08-24T09:01:52Z Carl Hetherington cth@carlh.net 2016-08-22T23:27:12Z urn:sha1:df28b0e939bd0f12ae31e6f7ba94fa954496b3b8 Fix seek through multi-reel DCP imports. 2016-08-16T13:30:53Z Carl Hetherington cth@carlh.net 2016-08-16T13:30:53Z urn:sha1:214843a6753b1b8b09789416c0c88e37e7ba039b 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. Don't bother decoding referenced DCP video if the player will ignore it. 2016-06-22T00:53:18Z Carl Hetherington cth@carlh.net 2016-06-22T00:53:18Z urn:sha1:282caacdd0f9283ee8c52b2c67b4696e071eba03 Set AudioDecoder::fast a different way. 2016-06-22T00:47:28Z Carl Hetherington cth@carlh.net 2016-06-22T00:47:28Z urn:sha1:76f83b97c401c24b3c93baee0665e84be05f43ea A couple of small optimisations. 2016-06-22T00:10:47Z Carl Hetherington cth@carlh.net 2016-06-22T00:10:47Z urn:sha1:5e9e59e044fe3b51352d5dccad7f11882c6a571c Revert "Use make_shared<>." 2016-06-21T22:08:53Z Carl Hetherington cth@carlh.net 2016-06-21T22:08:53Z urn:sha1:a8a0dfd1b21de6c0facf965ab119833ff6f790bf Support for this seems to vary wildly across DoM's build targets. Stuff that builds on 16.04 won't build on 14.04, for example. Seems to not be worth the hassle now. This reverts commit 5a5324ed3a381a86dfe0a6e3932c1d58fdcd596f. Use make_shared<>. 2016-06-21T00:14:06Z Carl Hetherington cth@carlh.net 2016-06-21T00:14:06Z urn:sha1:5a5324ed3a381a86dfe0a6e3932c1d58fdcd596f Use new libdcp reader interface. 2016-06-01T22:58:47Z Carl Hetherington cth@carlh.net 2016-06-01T22:58:47Z urn:sha1:368832f2ff6837d9029020b41fb97fb148c3be31