dcpomatic, branch v2.14.46DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=v2.14.462020-11-28T00:04:33ZBump libdcp for verification fix.2020-11-28T00:04:33ZCarl Hetheringtoncth@carlh.net2020-11-28T00:04:33Zurn:sha1:6c96c259064d6fe7bafe08a19502db57f39987dcFix corrupted image when over-cropping black filler frames.2020-11-24T23:11:55ZCarl Hetheringtoncth@carlh.net2020-11-24T23:11:55Zurn:sha1:accdec63a79b43c6349597b15243dc41e521521d
FFmpegDecoder can emit small black frames (128x128 pixels) when it
wants to fill in a gap. Image::crop_scale_window would do the wrong
thing if we then applied a crop of greater than 128 in either direction;
though cropped_size is correctly clamped, the crop value itself was
not and is used to calculate the input data pointers.
This would result in random frames, usually at the end of DCPs,
often made up of blurry colour washes.
Fix the behaviour of FileGroup when seeking too far.2020-11-24T22:08:35ZCarl Hetheringtoncth@carlh.net2020-11-24T22:01:04Zurn:sha1:82faf2d5817af3ca8d303a8e1b62f23bb461dcaf
Previously, if you did a seek off the end of the file group,
the seek would return an error.
This is not what fseek() does; it returns no error, and preserves
the file pointer (returned by ftell()) as if the seek had been
successful. fread()s after a too-far seek return no data, of
course.
Parsing some files (the example used to find the bug was a
H264 MP4) involves a seek which is to the byte after the end
of the mp4 file. If this fails the whole header parsing fails
and DCP-o-matic refuses to use the file.
Hack to fix image luminance when cropping subsampled images (#1872).2020-11-19T21:08:21ZCarl Hetheringtoncth@carlh.net2020-11-19T21:07:39Zurn:sha1:2456409a8db781d9ef505fc9e5f9290276ce6807
Without this the luminance varies slightly as you crop by odd and
even amounts (for YUV420 images).
Fix some GTK3 vertical alignment error messages in the player.2020-11-19T20:23:23ZCarl Hetheringtoncth@carlh.net2020-11-19T20:23:23Zurn:sha1:0ba91c0ce63953a8bbdbc9b43a8879b3e6d4ed29Test build fixes.2020-11-17T08:59:30ZCarl Hetheringtoncth@carlh.net2020-11-17T00:56:49Zurn:sha1:fd225e3afb0bcf3e7bfce1018dbc0a4c4bd275f2Tweak vertical spacing with GTK3.2020-11-17T08:59:30ZCarl Hetheringtoncth@carlh.net2020-11-17T00:18:01Zurn:sha1:236a1636c72edd424a7daf5b938c9da073439cd6Fix cropping of subsampled images.2020-11-17T08:59:30ZCarl Hetheringtoncth@carlh.net2020-11-16T23:00:50Zurn:sha1:27c0e43d75218b926068fff3d6d1364b476e56ff
The calculations for how to crop subsampled components of YUV images
were wrong, causing strange effects like misregistration of colour
components in cropped images. Should fix #1872.
Add some lrintf() calls to be sure.2020-11-16T23:18:02ZCarl Hetheringtoncth@carlh.net2020-11-16T22:58:53Zurn:sha1:451e5465bbd10827dafe76b35704102e589c0980Use 64-byte alignment for aligned image memory.2020-11-16T23:17:52ZCarl Hetheringtoncth@carlh.net2020-11-16T22:56:11Zurn:sha1:cdf9ebe4a827d8d2d6d89e34bad0c976b04834b7
FFmpeg uses this values if AVX512 is available, and with only
32-byte alignment I am seeing strange scaling effects whereby
crop_scale_window_test7 gives black bars down the right side of
cropped images (when run on an i7 7700).