| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
AV_PIX_FMT_XYZ12LE.
Prepare the image for where it is going to next. I don't understand the difference
in this situation between XYZ12LE and RGB48LE (it seems they are both 16-bit-per-channel)
but there you go.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We calculated the DCP time of the first frame (when its content was
trimmed) and it was clamped from -8 frames to 0, which meant it was used
when it should not have been.
|
|
We could write them separately (libdcp supports this, AFAIK) but
the Deluxe guidelines suggest not to use ClosedSubtitle or MainCaption.
|
|
|
|
|
|
Suddenly we have 8 commas, not 9, perhaps because of
29412821241050c846dbceaad4b9752857659977
in ffmpeg (although that's strange, because it was a long time ago).
|
|
We have to canonicalise relative paths with respect to the film's
directory on load, otherwise we try to use the relative path and it's
interpreted against the current working directory.
This unfortunately requires the film's directory to be piped into quite
a lot of new places.
|
|
|
|
|
|
(#2784).
This feels like a hack, but I can't think of a nicer way to do it.
The interruption disable makes sense because when we destroy encoder threads
during a DCP encode (because a remote server goes away, for example) we don't
want any frames to be lost due to the encode thread being interrupted between
taking the frame off the queue and sending it to the writer.
When we're destroying the encoder we don't care about this, but I can't see
how you'd differentiate.
Maybe the encoder queue could have two lists: to-do and in-progress;
the encoder thread atomically moves a frame from to-do to in-progress,
but then how do you know when the in-progress ones are orphaned and need
to be re-added to the main queue.
You could make the writer return saying "no" if the queue is full (rather
than blocking and waiting for the queue to empty) but that seems wasteful
as then the frame would be re-encoded.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Soon we'll add a new encoder type, and the existing structure was
already creaking a bit at the seams while handling local and remote
encodes. Here we split out an encoder thread and introduce the concept
of a "sync" thread (which blocks while the encoding is happening).
Later we'll have another type which submits the encode request to a
GPU and receives the reply back later.
|
|
|
|
|
|
|
|
with the same name in the same reel (#2600).
Previously we had this id_for_font_in_reel() which would give an ID
of N_font-ID. This means we got duplicate font IDs.
Here we replace that method with FontAllocator, which gives an ID of
N_font-ID for the first font and M_font-ID, where M is a number higher than
the highest reel index. The idea is to support the required new IDs
without breaking exisiting projects.
There is some documentation of how it works in doc/design/fonts
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FontConfig::_available_fonts to use the font ID as a key, but that's
totally wrong because the same Font object with the same ID can have
its font filename/data changed, and in that case we don't want to
use the cached font.
Here we use the actual TTF/OTF font data as the key. We could have
just hashed the data (whether it comes from a disk file or is held
in memory) but this is slower in the case where we have the filename,
as then the file must be loaded from disk for each comparison.
This fixes #2518.
|
|
|
|
If a template had content with N audio channels there would be various
problems if content with <N channels was subsequently added.
|
|
I'm far from convinced about the point/sense of all these "profiles"
(rather than just implementing or at least tolerating the standard)
but lots of people are having problems with "QC" processes failing
their DCPs with complaints related to MCASubDescriptors. It seems to
make sense to have an option to turn them off - at least for now,
until either the "QC" situation settles down or any bugs in DCP-o-matic
are found and fixed.
|
|
|
|
lie outside those of the KDMs (#2423).
|
|
|
|
Previously we would not account for the differences in what vertical
position means between Interop and SMPTE. For interop, vertical
position is the distance from the reference point to the text
baseline, whereas for SMPTE it is the distance from the reference
point to the top/middle/bottom of the subtitle (depending on the
reference).
This caused differences between the preview and the DCP for some
cases (notably, using SRT/SSA and making Interop DCPs, or converting
Interop DCP subs to SMPTE, or vice versa).
|
|
|
|
|
|
|
|
|
|
|
