dcpomatic/src/lib/player.cc, branch v2.10.2 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.10.2 2016-09-21T21:16:48Z Correctly spot that a DCP with unencrypted picture but encrypted sound/subtitle needs a KDM. 2016-09-21T21:16:48Z Carl Hetherington cth@carlh.net 2016-09-21T21:16:48Z urn:sha1:8457b7c1066da4e14f00a76f3855e60d986b179f Trim referred-to DCPs correctly using CPL entry point / duration. 2016-09-20T23:14:21Z Carl Hetherington cth@carlh.net 2016-09-20T23:14:21Z urn:sha1:f9d0bc389d3f36263fb7a3b54d2263878a8ea7fb Update view on changing subtitle fade. 2016-08-28T20:33:41Z Carl Hetherington cth@carlh.net 2016-08-28T20:33:41Z urn:sha1:36415c679621970b3c80fb910d8d0a57a8161682 Make burnt-in subtitle outline width configurable (#940). 2016-08-25T09:50:19Z Carl Hetherington cth@carlh.net 2016-08-25T09:50:19Z urn:sha1:4a5fcd19ca16447ba8b204986a378072a9c730b2 Basic support for fading subtitles in and out (#923). 2016-08-16T15:56:32Z Carl Hetherington cth@carlh.net 2016-08-16T07:41:25Z urn:sha1:94b3924ed3cbf4fbfa2445ca1007f25c53dc8b60 Remove unused variable. 2016-08-16T00:04:07Z Carl Hetherington cth@carlh.net 2016-08-16T00:04:07Z urn:sha1:1735af36a8fe197b1cc77b569b3933c74457d995 Support shadow in subtitles (#911). 2016-07-08T00:48:50Z Carl Hetherington cth@carlh.net 2016-07-08T00:30:39Z urn:sha1:ac2fa2172c30c234a19628d7a9ae696e435a56db Take y scale into account when deciding subtitle line spacing. 2016-07-02T22:52:54Z Carl Hetherington cth@carlh.net 2016-07-02T22:52:54Z urn:sha1:3dd6717ebb8766fd9ca2a9983e9d0bed69312d1e Make the preview respond to changes in subtitle line spacing. 2016-07-01T00:05:06Z Carl Hetherington cth@carlh.net 2016-06-29T23:20:49Z urn:sha1:9b7e3d7d992f64da4bc78bc99d1eb706f181b798 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.