dcpomatic/src/lib/player.h, branch debug/niclas DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=debug%2Fniclas 2018-02-24T23:35:11Z Speed some operations by re-using the last PlayerVideo but with 2018-02-24T23:35:11Z Carl Hetherington cth@carlh.net 2018-02-24T01:05:14Z urn:sha1:14cccb179fff7bbbf422e13f9d2e3264239c93c7 updated metadata (where possible). Helps with #1194. Fix implementation of delay in 7758260; it needs to apply to 2018-02-23T00:58:08Z Carl Hetherington cth@carlh.net 2018-02-23T00:57:04Z urn:sha1:24ba224ab4871e453df50fde94b5b32649a3d47b 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:37:24Z Carl Hetherington cth@carlh.net 2018-02-20T23:34:59Z urn:sha1:a0eff2446835a2a29d751a4810fe182c486a2eb6 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... 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.