DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.11.56 2017-04-19T22:04:32Z 2017-04-19T22:04:32Z Carl Hetherington cth@carlh.net 2017-02-21T21:42:44Z urn:sha1:89aa9d4ba69e471949f791cdafe4ae20cea554d2 2017-04-19T22:04:32Z Carl Hetherington cth@carlh.net 2016-12-13T15:02:09Z urn:sha1:eb135e8dcdf36ae82420bcd18e954ad593b3e9a5 2017-04-19T22:04:32Z Carl Hetherington cth@carlh.net 2016-12-13T14:51:39Z urn:sha1:22b13599407e45d85d1c83e0805aa14965b0ab19 2017-04-19T22:04:32Z Carl Hetherington cth@carlh.net 2016-11-21T16:57:15Z urn:sha1:de2af791bdfdcd653752cba970e59efc7bf810c7 2016-12-08T11:23:58Z Carl Hetherington cth@carlh.net 2016-12-08T11:23:58Z urn:sha1:a28ef704adf8c5bfa45b3d6285f741af64758ceb This fixes the failure to keep track of the `position' of each stream of a multi-stream file. It also tidies things up a bit. 2016-11-19T20:40:36Z Carl Hetherington cth@carlh.net 2016-11-19T20:40:36Z urn:sha1:f113b2aaca7a65f7b37e12a7d9f3f99e2d834e81 2016-11-19T00:51:05Z Carl Hetherington cth@carlh.net 2016-11-19T00:31:37Z urn:sha1:24e890682b3f2aa211277ad8b6b3591f2026d4be 2016-11-17T01:06:31Z Carl Hetherington cth@carlh.net 2016-10-07T15:22:38Z urn:sha1:97d39f46795af78b84d5f7bc9118a188f2864781 Before this commit, decoders try to guess whether they should request a seek based on what they have in their buffers. This seems reasonable for video and audio, which will always (I think) have some data lying around to give an indication of where their parent decoders are in the timeline. It doesn't work so well for subtitles, as the storage of subs is cleared out based on time (+/- 5s of "now") so there is a good chance that the storage will be empty. This gives the subtitle decoder no chance of knowing where its parent is, so it's very likely to seek. This commit asks the parent decoder to seek if it wants to, and it decides based on a knowledge of roughly where it is in the timeline. Hence the sub-decoders just see if they have got the data that is being requested, and if not they suggest to the parent that it might like to seek. They then start calling pass(). Hence the parent should only seek if some calls to pass() are not going to elicit the required data in a reasonable time. 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. 2016-05-25T19:56:58Z Carl Hetherington cth@carlh.net 2016-05-25T19:56:58Z urn:sha1:3828baf56467224f5d44049bf1e7a7ed11f43a05