| Age | Commit message (Collapse) | Author |
|
|
|
|
|
so that we don't have to run through the whole of the trimmed
portion to get to the data we want.
|
|
|
|
(related to #1246).
|
|
Without this we ask the AudioMerger to merge new buffers with N
channels with old buffers with M channels, which it can't do.
I'm not convinced this is the best solution but I think it will do
for now.
|
|
updated metadata (where possible). Helps with #1194.
|
|
|
|
|
|
anything passed to emit_video(), not just things that come from
decoders.
|
|
subtitle content the chance to catch up. Fixes problems observed
when overlaying a DCP subtitle onto an existing DCP and then seeking
into the first subtitle. After the seek the decoder positions were:
DCP: 0.
subtitle: first subtitle time.
This causes the DCP decoder to be pass()ed first and so the subtitle
for the video frame has not arrived yet.
I hope this does not cause unpredicted side effects...
|
|
|
|
|
|
|
|
data which were ignored by the Player.
2537a2d changed this so that Decoder::position() is always updated, as it could
not see the point of the previous behaviour.
It now seems that the behaviour prior to 2537a2d fixed problems with cases like
remake_with_subtitle_test. With this test the FFmpeg content happens to emit
a final frame just after its end point with a gap before it. Code prior to
2537a2d handled this by making sure that FFmpegDecoder::flush() filled the gap (it reads
VideoDecoder::position and fills the gap at the end of content accordingly).
This no longer works if VideoDecoder::position is updated to take into account
the emitted (and ignored) frame just after the end of the content.
This commit re-fixes that problem by a different means; Player::video now
fills the gaps in this case by more careful handling of received data which is
off the end of the content.
|
|
|
|
|
|
|
|
This clearly can happen with separate L/R sources. A pass in L might
emit two frames which means the arrivals can't possibly be in order.
This commit fixes this by introducing a Shuffler which all alternate-3D
sources send their video to. The Shuffler re-orders things before they
arrive at the player.
It also fixes the code which inserts video frames before one that arrives
after a gap. This didn't cope with 3D right before.
The audio code solves a similar (perhaps the same?) problem with the
AudioMerger; perhaps we should have a similar thing for video and make
the player emit complete 3D frames.
Should help with #976.
|
|
image-only content (e.g. crash1.xml in dcpomatic-test). We must consider
the _silent "source" to be like an audio stream when deciding when
to pull up to.
|
|
frame; may help with #1166.
|
|
|
|
|
|
|
|
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).
|
|
and also by the inability of content_video_to_dcp to return
negative values. The latter is necessary for tests on "is this
content too early" to work.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
at the end of the film (with no corresponding video).
|
|
of things that we are ignoring; this fixes strange behaviour (delays)
when analysing audio as it used to keep pass()ing decoders to get
data that would never come.
|
|
content.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
With a 29.97 source I had problems because the earliest decoder position was
one DCPTime quantum ahead of the last audio time; this looks like it was due to
the content-to-DCP time conversion using 1.001 as the ratio for 30/29.97 rather than
1.001001; I haven't investigated why. This all needs more careful consideration...
|
|
|
|
|
|
This call just doesn't take multi-stream into account. Removing it does
not trip any tests so I think it may be superfluous...
|