dcpomatic/test/shuffler_test.cc, branch processor DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=processor 2024-01-28T01:01:56Z Change how video timing is done. 2024-01-28T01:01:56Z Carl Hetherington cth@carlh.net 2022-09-29T08:17:50Z urn:sha1:895143459866dcb373c93b8e674d1344a129a6df This commit changes the approach with video timing. Previously, we would (more-or-less) try to use every video frame from the content in the output, hoping that they come at a constant frame rate. This is not always the case, however. Here we preserve the PTS of video frames, and then when one arrives we output whatever DCP video frames we can (at the regular DCP frame rate). Hopefully this will solve a range of sync problems, but it could also introduce new ones. Cleanup: test tidying. 2022-12-29T00:47:32Z Carl Hetherington cth@carlh.net 2022-12-29T00:47:32Z urn:sha1:ce73eaf7875a9a3326afcd839ad85eb95879c160 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.