dcpomatic/src/lib/player.cc, branch v2.11.78 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.11.78 2018-03-10T00:55:33Z Remove assert in emit_audio to work around #1206. 2018-03-10T00:55:33Z Carl Hetherington cth@carlh.net 2018-03-10T00:55:33Z urn:sha1:057a3fcfd98e5c8dec16294caf230aee2b5229eb Speed some operations by re-using the last PlayerVideo but with 2018-02-24T23:34:36Z Carl Hetherington cth@carlh.net 2018-02-24T01:05:14Z urn:sha1:d08123f5e160b5737fa912cd36119e810abaa4cd updated metadata (where possible). Helps with #1194. Another subtitle fix. 2018-02-23T19:55:23Z Carl Hetherington cth@carlh.net 2018-02-23T19:55:23Z urn:sha1:ca6079fb4e2e1b791aed70fc9ffc13f151eb62ea Fix thinko in previous. 2018-02-23T01:21:12Z Carl Hetherington cth@carlh.net 2018-02-23T01:21:12Z urn:sha1:ad15f80996bf14c7c33875a834cc07ed4dfd7214 Fix implementation of delay in 7758260; it needs to apply to 2018-02-23T00:57:04Z Carl Hetherington cth@carlh.net 2018-02-23T00:57:04Z urn:sha1:c8d104aa221bdccb0a11524c038b5f4c7c070554 anything passed to emit_video(), not just things that come from decoders. Add a 2-frame `delay' on content arriving at the player to give 2018-02-20T23:34:59Z Carl Hetherington cth@carlh.net 2018-02-20T23:34:59Z urn:sha1:775826079275839005d2168b190f96e32215afd0 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... 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.