| 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.
|
|
Without this the luminance varies slightly as you crop by odd and
even amounts (for YUV420 images).
|
|
|
|
|
|
|
|
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).
|
|
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.
|
|
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.
Backported-from-commit: 2c74c1534cb563cab4c6c3225ced573619f6a647
Backported-from-branch: v2.15.x
|
|
|
|
|
|
use of wxGraphicsContext. This seems to fix strange rendering
problems on Windows.
Backported-from-commit: 3e4f6d59b46e3c09c9d0aba907ff0633bf0bc2e5
Backported-from-branch: v2.15.x
|
|
|
|
|
|
|
|
|
|
for GTK3 so that they are at least vaguely usable.
|
|
|
|
|
|
|
|
|
|
Backported-from-commit: 86f855ef96a84ee7e8ad9d71b543e8c06fc91a9e
Backported-from-branch: v2.15.x
|
|
instead, assume it should be at timestamp 0.
Backported-from-commit: d7a3d94ec307a03ebe3fcf239ba991e9a3c1b8b8
Backported-from-branch: v2.15.x
|
|
hang around. Part of the fix for #1857.
Backported-from-commit: 9a3df0a97b7962c00726447a75599e34c632cb2b
Backported-from-branch: v2.15.x
|
|
containing files that are not in any PKL (#1855).
|
|
|
|
|
|
|
|
|
|
|
|
to write metadata to the "create in folder" directory, which throws
an uncaught exception if the specified directory is unwriteable.
If we have a name then DoM tries to create the directory with that name,
which fails more elegantly and with a nicer error.
Backported-from-commit: 50aaa3789864c7330ee92e7e89ad5b6cc2155a82
Backported-from-branch: 2.15.x
|
|
|
|
from Dolby.
Backported-from-commit: 746e298e214a65ca9151867b2948560e76b45546
Backported-from-branch: v2.15.x
|
|
Backported-from-commit: 23804b8beddd616cef60900d6e51deb7788cbd79
Backported-from-branch: v2.15.x
|
|
Backported-from-commit: 5f1fdbafc6eef37523250e0b8542a8939a038823
Backported-from-branch: v2.15.x
|
|
Backported-from-commit: d461077cf4f2c1470d2d0d6dbc4f5708411bec65
Backported-from-branch: v2.15.x
|
|
Cherry-picked from 591c73b472f0eb74225dbc1b08885f552b8814c4 in v2.15.x.
|
|
so that they can be displayed.
Cherry-picked from 09860271bb6d03b3937c08bffb4c672697f6d711 in v2.15.x.
|
|
Cherry-picked from d902160e3c89a9f65f58a2463fac0b1de1d940b1 in v2.15.x.
|
|
DVD rips from NTSC DVDs are sometimes (always?) encoded using
soft 2:3 pulldown. The video frames are actually 23.976 but
FFmpeg detects them as 29.97. With the current approach of the video
decoder ignoring most PTSs and assuming a constant frame rate
it is vital that the file contains the number of frames per second
that the detected frame rate predicts.
This fixes large sync errors with NTSC DVD rips (#1790).
Cherry-picked from af680761cf7c3e97660e8e55c68f42e90b026bf9
in v2.15.x.
|
|
is running as clicking the higher ones will cause an assertion
failure.
Cherry-picked from 4b5e05b9845d609524328a88a81011b364e03a8a in
v2.15.x.
|
|
analysis window while the analysis is running.
Cherry-picked from 6b1d9adcf6e75fc8e441b61108a2169bda6a6094 in
v2.15.x.
|
|
inclusive fails, at least for AAC. There's probably a way around
this with some FFmpeg-cleverness but for now let's just export any
project with more than 8 channels as 16.
You could argue that we should offer choices to, for example
export 7.1/HI/VN as 7.1 but that sounds fiddly.
Fixes #1786.
|
|
|
|
|
|
|