dcpomatic/src/lib/player.cc, branch v2.11.58 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.11.58 2018-02-16T23:53:01Z Add log for assertion failure. 2018-02-16T23:53:01Z Carl Hetherington cth@carlh.net 2018-02-16T23:52:39Z urn:sha1:62890d211dd114c90e2f661ebbabd999850df6c3 Fix ignore/referencing logic. 2018-02-07T20:14:19Z Carl Hetherington cth@carlh.net 2018-02-07T20:14:19Z urn:sha1:8bfe295dcc4e1753ee1c89310108bc6bc034cd61 Whitespace. 2018-02-02T23:58:33Z Carl Hetherington cth@carlh.net 2018-02-02T23:58:33Z urn:sha1:a13c66be5c55a81fd9a57131cf25b2760e31f38e Prior to 2537a2d Decoder::position() was not updated if a decoder emitted 2018-02-02T23:47:46Z Carl Hetherington cth@carlh.net 2018-02-02T23:47:46Z urn:sha1:518be532a480173dfac962d5aca347a2388bb072 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. Fix missing subtitles when they start just after the start of a frame. 2018-01-31T21:36:36Z Carl Hetherington cth@carlh.net 2018-01-31T21:36:36Z urn:sha1:8bccd0af23b8e1ada43182c2531c21f06036ca37 Fix sequencing failure in some very specific circumstances. 2018-01-31T00:25:06Z Carl Hetherington cth@carlh.net 2018-01-31T00:25:06Z urn:sha1:a5d5ceb22c4f5dd3e6c5b7a8da76f724dd266a75 Fix assertion failure in emit_audio. 2018-01-30T00:34:13Z Carl Hetherington cth@carlh.net 2018-01-30T00:34:13Z urn:sha1:c463929602252be95ca340b477b7f3b42ff6b0c0 In general the player assumes that it won't receive out of order video. 2018-01-16T21:01:30Z Carl Hetherington cth@carlh.net 2018-01-16T21:01:30Z urn:sha1:1aad2c33896ce6222f3c929c7af7fe4ff5fda0f2 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. Fix incorrect reel lengths when start-trimmed movie content follows 2018-01-15T00:42:58Z Carl Hetherington cth@carlh.net 2018-01-15T00:42:58Z urn:sha1:1a0aeb9b5639f31dc50e4a2c72c4dc33899a7d4a 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. Only put subtitles in a frame if they overlap more than half of that 2018-01-14T02:27:04Z Carl Hetherington cth@carlh.net 2018-01-14T02:27:04Z urn:sha1:1f33b815df5d780f123c6bdf8f110a4f2fc70363 frame; may help with #1166.