| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Also make it return open captions as well as open subtitles (#2941).
|
|
We could write them separately (libdcp supports this, AFAIK) but
the Deluxe guidelines suggest not to use ClosedSubtitle or MainCaption.
|
|
|
|
The motivation here is to stop a pattern where we create a file, close
it, and then re-open it (many times) as I think there are problems on
Windows when a virus scanner sees the new file, opens it for checking,
and then we can't re-open it.
This also makes things a fair bit simpler, as a lock is removed and we
don't try to differentiate read/write cases by opening the file in
different ways; it's now always writeable.
|
|
|
|
to get a more accurate error number on Windows.
|
|
|
|
|
|
Instead store details of a previously-created asset in the film's
metadata and then look there for potential video files to re-use.
|
|
|
|
(#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.
|
|
|
|
|
|
other DCPs (in a VF) that themselves might have missing subtitles
for some reels.
|
|
|
|
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
|
|
anything that is passed to read_file() from libcxml.
This should fix #2623 and other similar problems.
|
|
|
|
the MXF.
|
|
|
|
|
|
|
|
|
|
|
|
2f12058c535045cecc226fe47b3d60da8851a862
|
|
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.
|
|
Previously if there was 2D content in a 3D project (or vice versa)
the player would emit the video anyway and the encoder would have
to deal with it.
Since previously the FFmpeg encoder did not deal with this quite
right, it seems to make sense to move the logic into the player
so that neither encoder has to worry about it.
|
|
|
|
|
|
|
|
|
|
With this change each subtitle coming out of the player has a reference
to a dcpomatic::Font that belongs to the TextContent. This hopefully
solves a few problems which all basically stemmed from the fact that
previously the decoders/player were deciding what the font ID in the
output DCP would be - they can't do that properly.
|
|
|
|
|
|
|
|
|
|
I can't see the problem with this, but apparently Dolby
CineInspect complains about it.
We could fix this in libdcp but I think that would make more sense
if this were related to a definite standard violation, instead of
just some tinkering to hide a possibly-incorrect warning.
|
|
|
|
|
|
|
|
It feels neat to have audio language in the audio tab, to match
the subtitle language in the subtitle tab. It also avoids the potential
confusion of there being an audio language setting in the DCP metadata
but no subtitle language setting. However:
- I am yet to find a need to describe multiple audio languages in the
same DCP (all previous users of Film::audio_languages() were just taking
the first language off the list).
- As Carsten points out it's fiddly to have to set the audio language
for 5 separate-channel WAV files, for example (you wouldn't actually
have had to do this, but it would have felt like you did).
I think subtitle language remains neater where it is (per-content)
as there is this additional subtitle language metadata and it makes
much more sense (and is much more likely) that there are multiple
subtitle languages in a DCP than it does multiple audio languages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also adds the main/additional language flag.
Of all the considerations about how to specify subtitle language,
the most important seems to be that the language specification happens
for the content where the language is; i.e. in the content text tab.
|
