| Age | Commit message (Collapse) | Author |
|---|
|
sed -i "/include.*compose.hpp/d;" src/lib/*.cc src/wx/*.cc src/wx/*.h src/tools/*.cc src/lib/*.h test/*.cc
|
|
sed -i "/Plural-Forms/n;/%100/n;/scanf/n;s/%[123456789]/{}/g" src/lib/*.cc src/lib/*.h src/wx/*.cc src/tools/*.cc src/lib/po/*.po src/wx/po/*.po src/tools/po/*.po test/*.cc
sed -i "s/String::compose */fmt::format/g" src/lib/*.cc src/lib/*.h src/wx/*.cc src/tools/*.cc test/*.cc
|
|
|
|
This commit changes the approach with video timing. Previously,
we would (more-or-less) try to use every video frame from the content
in the output, hoping that they come at a constant frame rate.
This is not always the case, however. Here we preserve the PTS
of video frames, and then when one arrives we output whatever
DCP video frames we can (at the regular DCP frame rate).
Hopefully this will solve a range of sync problems, but it
could also introduce new ones.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in 2D projects. Also add some tests.
|
|
|
|
|
|
3D tests with more parallel jobs to speed them up.
|
|
|
|
|
|
if the data that was emitted from the decoder was not taken by the player.
This means that when the decoder moves into its end trim the position will
stay where it is (since the player does not take the data).
I can't see the point of doing this; the only use of Decoder::position()
is to decide what to pass() next (I think).
It is also inconvenient because we would like to check Decoder::position()
to decide whether to stop passing a decoder since it's in its end trim
(not doing this causes #1154).
|
|
|
|
rejected by the player, and for initial audio not to be at time 0.
|
|
Trying to repeat in VideoDecoder is the wrong side of the distinction
between content and DCP time; the repeat is for the DCP and VideoDecoder
should be emitting in terms of the source.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes the failure to keep track of the `position' of
each stream of a multi-stream file. It also tidies things
up a bit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Before this commit, decoders try to guess whether they should
request a seek based on what they have in their buffers. This
seems reasonable for video and audio, which will always (I think)
have some data lying around to give an indication of where their
parent decoders are in the timeline.
It doesn't work so well for subtitles, as the storage of subs is
cleared out based on time (+/- 5s of "now") so there is a good chance
that the storage will be empty. This gives the subtitle decoder no
chance of knowing where its parent is, so it's very likely to seek.
This commit asks the parent decoder to seek if it wants to, and it
decides based on a knowledge of roughly where it is in the timeline.
Hence the sub-decoders just see if they have got the data that is being
requested, and if not they suggest to the parent that it might like
to seek. They then start calling pass(). Hence the parent should only
seek if some calls to pass() are not going to elicit the required data
in a reasonable time.
|
|
|
|
|
|
|
|
|
|
With referenced video from a DCP decoder, no video will ever
be fetched from the decoder. Hence the code to discard given video
will be activated after _decoded builds up to the magic size.
Before this commit the code would attempt to fill with black up to
given frame N (with N very large) from the last frame in _decoded when
_decoded had been trimmed. This would result in exponential growth
in execution time for the VideoDecoder::give() path.
|
|
Support for this seems to vary wildly across DoM's build
targets. Stuff that builds on 16.04 won't build on 14.04,
for example. Seems to not be worth the hassle now.
This reverts commit 5a5324ed3a381a86dfe0a6e3932c1d58fdcd596f.
|
|
|
|
|
|
|
|
This puts a frame index with an Eyes, which simplifies code in
some areas. I can't think of a better name for it,
unfortunately.
|
