dcpomatic/src/lib/image_decoder.cc, branch v2.9.13DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=v2.9.132016-06-29T15:01:14ZFix handling of incorrectly-recognised JPEG2000 files.2016-06-29T15:01:14ZCarl Hetheringtoncth@carlh.net2016-06-29T15:01:14Zurn: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.
No-op; fix GPL address and use the explicit-program-name version.2016-05-25T19:56:58ZCarl Hetheringtoncth@carlh.net2016-05-25T19:56:58Zurn:sha1:3828baf56467224f5d44049bf1e7a7ed11f43a05Rename some methods.2016-05-18T10:50:29ZCarl Hetheringtoncth@carlh.net2016-05-10T13:37:57Zurn:sha1:0758d834992f0adb8aa8d4d9908a64ce8708f05cBasics of splitting up Decoder tree like Content.2016-05-18T10:50:29ZCarl Hetheringtoncth@carlh.net2016-05-10T13:29:14Zurn:sha1:504c63b3d62038bc486ca8a09e77fbb403907eddMove video frame rate ('prepared-for') into Content.2016-05-18T10:50:29ZCarl Hetheringtoncth@carlh.net2016-05-09T18:58:37Zurn:sha1:19f94521139aac13ef8fb4eaa55855b2ada307b4Rename video/audio/subtitle part methods.2016-05-18T10:50:29ZCarl Hetheringtoncth@carlh.net2016-04-14T01:06:18Zurn:sha1:2d5beb0d6794df13ad1df47e84fd7a57d1d1c64dReasonably straightforward stuff; main things are adding2016-05-18T10:50:29ZCarl Hetheringtoncth@carlh.net2016-04-12T21:10:54Zurn:sha1:6f344b876689a1234a5eb75041882f06f5d9fe5c
a _parent to VideoContent (mainly, but not only, for signalling)
and moving the video shared_ptr into Content, which makes much
more sense to replace dynamic_cast tests for whether something
has video or whatever. Nearly builds.
Reinstate subtitle speed-up patch 526fd6de4c80a7ac9614a1cb0209efff7b171cd5 but only for preview.2015-10-26T09:37:29ZCarl Hetheringtoncth@carlh.net2015-10-26T09:37:29Zurn:sha1:2e62b2c0de47fc8e5bcb5466b2876f9b23d2ae84Revert "Avoid decoding other packets when looking for subs."2015-10-23T15:12:14ZCarl Hetheringtoncth@carlh.net2015-10-23T15:12:14Zurn:sha1:526fd6de4c80a7ac9614a1cb0209efff7b171cd5
This reverts commit 9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49.
It causes corruption in prophet_clip.xml for reasons that
are not yet known.
Avoid decoding other packets when looking for subs.2015-10-16T13:38:44ZCarl Hetheringtoncth@carlh.net2015-10-16T13:38:44Zurn:sha1:9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49
The "accumulation" of, for example, video data when we are looking
for audio data is an *optimisation* to reduce the number of seeks.
It should not be necessary for correctness (the output should be right
even if we never kept anything except what we were looking for).
Doing this accumulation is not always an optimisation; sometimes not
doing it is better. Avoiding it when going back for subtitles is one
of these cases.