dcpomatic/src/lib, branch v2.15.111

Fix over-read behaviour of FileGroup to be the same on all platforms.

2020-11-28T19:58:56Z

Instead of relying on the operating system's behaviour when seeking off the end of a file, keep our own _position. This normalises the behaviour between POSIX and Windows.

If we don't query a server (because we already know about it)

2020-11-26T01:24:32Z

the "last seen time" will never be updated, so the server will be discarded. It seems that we should always ping servers (so that set_seen gets called on receipt of the response), no matter whether "auto-discovered" or configured, so that the "discard" code doesn't kick in. Otherwise we remove and re-add our configured servers every 10 seconds, which is inefficient and which possibly triggers other bugs.

It feels unsafe not to lock _threads_mutex between terminate_threads()

2020-11-26T01:04:25Z

and _threads.reset(); move the lock.

Calculate hashes for any referenced assets that do not already have one.

2020-11-26T00:49:33Z

This is necessary so that we always include in CPLs even when referencing DCPs that do not have it.

Use a foreach.

2020-11-26T00:49:19Z

Disallow referring to subtitles / closed captions with start trim.

2020-11-25T22:58:25Z

Since per Bv2.1 we can't have subs / closed captions with non-zero entry point I think we have no choice but to rewrite in that case (#1802).

Check for inconsistency in settings for referring to text.

2020-11-25T22:57:52Z

Just as we do for picture / sound.

Remove unused method.

2020-11-25T12:14:44Z

Fix corrupted image when over-cropping black filler frames.

2020-11-24T23:36:22Z

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:01:04Z

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.