dcpomatic/src/lib/player.cc, branch v2.11.46 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.11.46 2018-01-31T00:25:06Z 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. Use an enum for the effect in SubtitleContent. 2018-01-13T00:06:28Z Carl Hetherington cth@carlh.net 2018-01-12T13:24:52Z urn:sha1:67a404fff364c6e1fa02eab270755895ba0e1fe8 Recreate player pieces when changing FFmpeg filters (#1019). 2018-01-04T22:02:27Z Carl Hetherington cth@carlh.net 2018-01-04T22:02:27Z urn:sha1:daf6233204d381de4ec1d3a6c08c06d5973f9b90 Mark pieces as done when we're past the end of them; fixes #1154. 2018-01-02T21:21:43Z Carl Hetherington cth@carlh.net 2018-01-02T21:21:43Z urn:sha1:65c3b3a815545fef4d0373bb588eb815b8b544b0 A previous commit took care to make Decoder::position() not be updated 2018-01-02T21:09:36Z Carl Hetherington cth@carlh.net 2018-01-02T21:09:36Z urn:sha1:2537a2d959a5872c2e75b322022a7679d24c7e60 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). Fix various problems caused by non-integer-frame start trims, 2017-12-11T01:06:37Z Carl Hetherington cth@carlh.net 2017-12-11T01:06:37Z urn:sha1:14c5566fe90b2584c7474c3250e6506d70e81510 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.