| Age | Commit message (Collapse) | Author |
|---|
|
3D tests with more parallel jobs to speed them up.
Backported from 11c07c6fd98620c859c7d3dcf6a4bbf6a05e567e in v2.15.x.
|
|
|
|
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.
|
|
get_video() promises to return all video frames at the given time,
but this wasn't working for none-SBS-3D as it would be satisfied
when it got the first (left) frame. Adjust get_video() to get all
required frames.
This showed up bugs in fill_both_eyes, whereby the from parameter
was ignored and the wrong things were done in some cases;
video_decoder_fill_test.cc tests this stuff.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Don't stop returning stuff from get_video when there are frames
left in _decoded_video.
|
|
|
|
to get an earlier frame has already failed because the decoder
said it has no more data. Before this the VideoDecoder would
repeatedly seek to try to get a frame which does not exist.
This happens when the header of a file is wrong, it would seem;
in the file that triggered the bug the header (as read by DoM or ffprobe)
has a length of 137275 frames but the last frame in the file
(according to DoM or ffprobe -show_frames) is 136207 (44.5s earlier).
|
|
|
|
|
|
but only for preview.
|
|
This reverts commit 9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49.
It causes corruption in prophet_clip.xml for reasons that
are not yet known.
|
|
I am reasonably convinced that the accumulation of _decoded_video
is an optimisation rather than being required for correctness,
so it's no problem to throw frames away as the code will just
get them back again if and when it needs them.
|
|
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.
|
|
|
|
|
