| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
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.e. as a block of memory rather than a file. Also, get the
fonts from the decoder rather than the content.
Together, these changes allow us to use fonts from SMPTE DCPs
added as content. Before, fonts would be messed up in those
cases (#1885).
|
|
are re-written, meaning that they can be encrypted.
This (along with the libdcp update) also fixes assorted Atmos bugs.
|
|
_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.
|
|
This has the same cause as
19f51503621a57794bd79bac053c9e6549a69f46
i.e. the DCPDecoder re-use optimisation. This commit tries to
re-fix 19f515 in a more general way which also takes into account
the OV/VF bug. It also adds a unit test.
|
|
|
|
(if available) to recover the list of reels from, rather than having
to scan the filesystem again.
|
|
|
|
|
|
|
|
|
|
|
|
ActiveCaptions -> ActiveText
BitmapCaption -> BitmapText
ContentCaption -> ContentText
ContentTextCaption -> ContentStringText
TextCaptionFileContent -> StringTextFileContent
TextCaptionFileDecoder -> StringTextFileDecoder
TextCaptionFile -> StringTextFile
TextCaption -> StringText
PlayerCaption -> PlayerText
CaptionContent -> TextContent
CaptionDecoder -> TextDecoder
CaptionPanel -> TextPanel
CaptionView -> TextView
CaptionAppearanceDialog -> SubtitleAppearanceDialog
CaptionType -> TextType
|
|
hold subs and closed captions.
|
|
|
|
on frame-advance (and in other cases).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a _parent to VideoContent (mainly, but not only, for signalling)
and moving the video shared_ptr into Content, which makes much
more sense to replace dynamic_cast tests for whether something
has video or whatever. Nearly builds.
|
|
|
|
but only for preview.
|
|
This reverts commit 9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49.
It causes corruption in prophet_clip.xml for reasons that
are not yet known.
|
|
The "accumulation" of, for example, video data when we are looking
for audio data is an *optimisation* to reduce the number of seeks.
It should not be necessary for correctness (the output should be right
even if we never kept anything except what we were looking for).
Doing this accumulation is not always an optimisation; sometimes not
doing it is better. Avoiding it when going back for subtitles is one
of these cases.
|
|
|
|
|
|
|
|
|
|
|
|
This feels wrong: it means that it is possible for FFmpegDecoder
to discard packets. I can't see how this is ok in all cases:
maybe we were lucky that it worked at all.
|
|
subtitles.
|
|
|
|
|
|
|
|
|
