dcpomatic/src/lib/shuffler.cc, branch v2.12.2 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.12.2 2018-02-23T00:57:04Z 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... Remove some debugging code. 2018-02-02T09:57:29Z Carl Hetherington cth@carlh.net 2018-02-02T09:57:29Z urn:sha1:5e0a4699d50931aafaca2801fa8b010549ab3abc 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.