| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
It just seemed to cause more problems than it solved; mainly people
enabling it by mistake and then being told to click buttons that
they could not see.
|
|
|
|
|
|
|
|
|
|
|
|
to SMPTE extended metadata.
|
|
|
|
in older films.
|
|
|
|
languages from the Interop/SMPTE metadata dialogues.
|
|
|
|
This is a speculative fix which I haven't tested.
|
|
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.
|
|
|
|
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).
|
|
Our export formats all currently use limited range but we weren't
making sure data fed to the encoders was limited range.
Should fix #1832.
|
|
|
|
they have borders. This fix will cause some movement of border-less
subtitles (in existing projects) within the video frame.
|
|
|
|
|
|
|
|
Video that comes in with RGB pixels will not have its video level
ranges changed by libswscale (it only does this for YUV and greyscale).
Here we add code to do it ourselves for RGB content coming in
via image files (e.g. PNG/DPX etc). Part of #1851.
|
|
|
|
This is checked later, anyway (without asserting) and we have seen
files in the wild with other rotations (e.g. -135.62) which do not
appear to need rotation to be applied.
Fixes #1871.
Backported-from-commit: f235ed07f969e1b8b9d3d05082dcdd68ceae771e
Backported-from-branch: master
|
|
|
|
|
|
73ebb92e9df01ba7afb97121b6e2cef6ca13a18e
I'm not sure why it was removed, and it seems necessary;
servers_list_changed() can be called from a variety of different places
(the constructor and two different EncodeServerFinder threads).
May help with #1854.
|
|
This reverts commit 4cf45229bf55344e708fead769f694f13bacf39c.
It's wrong - the sign language channel is 15 (1-indexed) not 15
(0-indexed) as in this commit.
|
|
of 4MB of data for every JPEG2000 frame we decode.
|
|
|
|
their own sign language tracks until DoM supports them properly.
|
|
|
|
ASSETMAP{,.xml} in the top level.
This should avoid some confusion, as previously DoM would scan the
whole directory tree looking for an ASSETMAP. It also prevents
people adding a DCP-o-matic project to itself, which I believe is the
cause of #1620.
|
|
|
|
TextContent::set_dcp_track can end up requesting a view update, which
involves calls to methods in Content which lock the Content::_mutex.
Do these calls without a lock on that mutex held.
Also, it looks like we would append to texts on every call to
examine(). Fix that so that we replace the texts list on each
examine() call.
|
|
instead, assume it should be at timestamp 0.
|
|
hang around. Part of the fix for #1857.
|
|
Windows. I haven't been able to find any conclusive explanation for
why this stuff happens;
https://stackoverflow.com/questions/7241168/safe-maximum-number-of-records-read-by-fread
is one possible lead.
|
|
directory as tests rely on it.
|
|
|