| Age | Commit message (Collapse) | Author |
|
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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
Backported-from-commit: 5f1fdbafc6eef37523250e0b8542a8939a038823
Backported-from-branch: v2.15.x
|
|
Backported-from-commit: d461077cf4f2c1470d2d0d6dbc4f5708411bec65
Backported-from-branch: v2.15.x
|
|
so that they can be displayed.
Cherry-picked from 09860271bb6d03b3937c08bffb4c672697f6d711 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.
|
|
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.
|
|
|
|
Backported from 8c7ad603cf0a534abe1a920b70b0daa095257d3a in v2.15.x
|
|
|
|
|
|
so that the thread is gone before the object is torn down.
|
|
the same time (github #7).
Back-ported from c403e757cf0b029954fe18dc969314bfb179412f in v2.15.x.
|
|
|
|
|
|
|
|
Required because of the change to the way video frame timing
is done.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
then convert it back to resampled content frames using the DCP
rate rather than the resampled content rate, which seems wrong.
If we want to go from metric time to frames we surely have to use
the frame rate of the thing we are working with (not the frame rate
which that thing will be played back at).
Backported from 26c62598730d1d32333bfab0d5f463b90d26ee4d in v2.15.x.
|
|
Before this fix, the following situation could happen in threads
A and B:
A: Some DONE signal happens; this triggers setup_pieces which
takes a lock on the player mutex.
B: FFmpegContent::examine takes a lock on the content mutex.
B: FFmpegContent::examine adds a stream
B: That causes STREAMS PENDING to be emitted.
B: This tries to take a lock on the player mutex so it can update _suspended
A: setup_pieces tries to access some content information, hence
tries to take a lock on the content mutex.
Now B is holding the CL and awaiting the PL and A is holding
the PL and awaiting the CL.
It feels like the root cause of this is that while setup_pieces
is happening another change (which would itself cause setup_pieces)
is announced, and this isn't dealt with properly.
There are two steps here; _suspended is protected with an atomic
rather than using _mutex, and also it can cope with being updated
recursively.
Backported from df48c75c38dd788835a93540aea243a2dac4bb10 in v2.15.x
|
|
Back-ported from 98342fb53eae4d32440fc69c279f2ca0fef785b5 in v2.15.x.
|
|
Back-ported from dec5ae11238495c64fffdab37f189d96aed7d636 in v2.15.x.
|
|
|
|
|
|
|
|
bitmapped subtitle colours.
Backported from 74168425c45987b45d4f4e147fb45fab33c3cab9 in v2.15.x.
|
|
|
|
|
|
Backported from 2ba5edb6761dbb14e4906200cb4e57c4180541ff in master.
|
|
file belongs to.
Backported from 0dca360f831aa51a4c0a33caa18e78c07391f3b7 in v2.15.x.
|
|
_next time.
This is important because Decoder::position does the wrong thing
with DCPs in the following case.
1. DCPDecoder emits a subtitle event (start/stop) at time t.
2. There follows a long time T with no subtitle events. During
this time the DCPDecoder's position is reported as t (since
TextDecoder notes its position as the time of the last thing
it emitted --- which is all it reasonably can do, I think).
3. During this T the DCPDecoder may be incorrectly pass()ed because
its position is reported as earlier than it really is; this results
in video/audio being emitted by the DCPDecoder but other contemporary
sources may not be pass()ed.
The upshot of this can be that no audio is emitted, as a contemporary audio
source is not pass()ed and hence the merger is waiting for audio that will
take a long time to come. When the butler is running this can result in
audio underruns as the video buffers overflow with no sign of any audio.
It is also simpler this way; DCPDecoder was already maintaining the required
information.
|
|
coming from the content and the calculated periods of silence.
It sees that there is some scope for disagreements here when
trim start/end times are rounded to frame boundaries.
Fixes #1708.
|
|
|
|
cause weird problems when scanning some files. The unit test case
added here is a case in point: before this patch one
stream reported an incorrect channel count and sample rate.
It's a bit worrying as these parameters have been in DoM for many years,
but perhaps they have become unnecessary / harmful with changes to FFmpeg.
|
|
resamplers are emptied and hence we don't lose any
samples. Fixes #1691.
|