dcpomatic/test/shuffler_test.cc, branch foo DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=foo 2021-01-31T02:14:24Z More enum class additions. 2021-01-31T02:14:24Z Carl Hetherington cth@carlh.net 2021-01-31T02:14:24Z urn:sha1:8fedaaa75c4586a4cc7ffb393bd71d1fdb091dc8 std::shared_ptr 2021-01-07T21:48:29Z Carl Hetherington cth@carlh.net 2021-01-04T20:16:53Z urn:sha1:dd9be86db6cde0afa5da0d1d1ac43b42e05dca26 Some macOS test build fixes. 2020-10-13T16:51:11Z Carl Hetherington cth@carlh.net 2020-10-08T19:30:00Z urn:sha1:497803ab4424ce23affd231a01d625ddf3cf3aca Fix test after Shuffler changes. 2019-02-13T09:57:09Z Carl Hetherington cth@carlh.net 2019-02-13T09:57:09Z urn:sha1:af7fe636291ee7f75f86b19d55713a595b24636c Fixes to 3D shuffler to fix #1463. 2019-02-13T00:17:10Z Carl Hetherington cth@carlh.net 2019-02-13T00:17:10Z urn:sha1:27fbe80bccafe744ca3f96129c9e582f39921891 Make the shuffler longer; I've seen examples where the video and sound are over a second apart within the muxed file. Allow the shuffler to pass through complete missed frames; e.g. if the input is L1 R1 L3 R3 we can pass that through without worrying about the missing frame #2. Add a log warning if the shuffler fills: at this point, 3D sync may be lost. Further adjustment of shuffler to cope with having sources for only one eye. 2018-04-05T15:31:18Z Carl Hetherington cth@carlh.net 2018-04-05T15:31:18Z urn:sha1:5f5c64faa7b0114f84f45e50211611333042c672 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.