dcpomatic/src/lib/player.h, branch v2.11.45 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.11.45 2018-01-16T21:01:30Z 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. Add comment. 2018-01-15T23:14:00Z Carl Hetherington cth@carlh.net 2018-01-15T23:14:00Z urn:sha1:598483f71fabde104250296ab4bfe4ec70d82d66 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 incorrect reel lengths in some cases; account for emitted data being rejected by the player, and for initial audio not to be at time 0. 2017-08-29T23:59:26Z Carl Hetherington cth@carlh.net 2017-08-29T23:59:26Z urn:sha1:9ba99535750e19c341f6ff535c6c8991658a8fbb Basics of forced reduction of JPEG2000 decode resolution. 2017-08-14T20:07:49Z Carl Hetherington cth@carlh.net 2017-08-03T16:54:06Z urn:sha1:0253b4e45c71a1c2e2a8bffaf1c3cb84a0a3e41a Add some tests; fix failure to make DCP when there is a bit of audio right at the end of the film (with no corresponding video). 2017-07-12T14:21:31Z Carl Hetherington cth@carlh.net 2017-07-12T14:21:31Z urn:sha1:2517ec798da291dedc02dd7a7a432f7aa63133e4 Remove unused Player::_ignore_audio. Ignore position 2017-07-11T13:46:52Z Carl Hetherington cth@carlh.net 2017-07-11T13:46:52Z urn:sha1:081f974c2c75c306d07d5a6f5da6847826a05a9c 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. Fixes for silence in projects, various cleanups. 2017-06-29T10:26:13Z Carl Hetherington cth@carlh.net 2017-06-28T09:09:53Z urn:sha1:baf84885a777378b9ff5c05ef24d6361560822a6 Add a OV/VF test; tidy up a bit. 2017-06-23T19:35:15Z Carl Hetherington cth@carlh.net 2017-06-23T19:35:15Z urn:sha1:4fbe44913582d6cc48a7d61145f3170fb0eec595 Do resampling in AudioDecoder rather than Player. 2017-05-21T18:48:14Z Carl Hetherington cth@carlh.net 2017-05-21T18:48:14Z urn:sha1:fa4d2529d63bcfa7cf7c516b7227e20a1b6dec7e This fixes the problem where the decoder's position would not take into account that all samples pushed into the resampler do not always immediately come out. This would result in Player thinking that there would be gaps when there are not.