dcpomatic/src/lib, branch v2.14.3 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.14.3 2019-05-21T00:50:07Z Give an error if 2D content is set to 3D (#1565). Also run 2019-05-21T00:50:07Z Carl Hetherington cth@carlh.net 2019-05-21T00:47:22Z urn:sha1:c5f67166138c3849cc49f1223742343ce4b11b9f 3D tests with more parallel jobs to speed them up. Backported from 11c07c6fd98620c859c7d3dcf6a4bbf6a05e567e in v2.15.x. Updated de_DE translation from Carsten Kurz. 2019-05-10T13:35:43Z Carl Hetherington cth@carlh.net 2019-05-10T13:35:43Z urn:sha1:a9ce4f64658979bc15c301b53c76846072fda0ef Add new ko_KR .po files. 2019-05-10T12:12:32Z Carl Hetherington cth@carlh.net 2019-05-10T12:12:32Z urn:sha1:a8a3d3759e5104a36e6d4b36f3a572b0bf672470 Updated fr_FR translation from Thierry Journet. 2019-05-07T19:52:40Z Carl Hetherington cth@carlh.net 2019-05-07T19:52:40Z urn:sha1:8242f46a4e3b0b6586613d70f8e07b1782ca2eeb Updated nl_NL translation from Rob van Nieuwkerk. 2019-05-05T22:32:40Z Carl Hetherington cth@carlh.net 2019-05-05T22:32:40Z urn:sha1:a49c3824e1b88e37a58a05b9142008ccd192d3d3 Stop video filters emitting frames from the old position just 2019-05-05T22:23:40Z Carl Hetherington cth@carlh.net 2019-05-05T22:23:40Z urn:sha1:72253f423319c8ff727acf3324617c206b984ae1 after a seek. If this happens, we get sequences like 1. emit some video at time 60s 2. seek to 40s 3. video frame emitted from filter at 60.1s; this sets _last_video_time in player so that frames emitted between 40s and 60s are discarded; hence the audio buffers overflow. Should fix #1551. Fix case where the is FFmpegContent with 24fps video and 44.1kHz audio 2019-05-05T20:49:51Z Carl Hetherington cth@carlh.net 2019-05-05T20:49:51Z urn:sha1:870ab8d9295b9d4b6605e8876919d23379dc3a35 and a start trim of 6724000. With these numbers the start trim is on an integer video frame but halfway through an audio frame. Without this patch the trim would be "corrected" to 6724001, causing video frames to come out of the player at DCPTimes 0, 3999, 5999 etc. It's possible that Frame const position = time.frames_floor(_film->video_frame_rate()); in J2KEncoder::encode should be frames_round, which would also help with this, but that would be a much more risky patch. pot/merge. 2019-05-05T19:21:32Z Carl Hetherington cth@carlh.net 2019-05-05T19:21:32Z urn:sha1:e520a3367ce293b0e9d2075f071dbdd854b15a21 Fix some formatting errors in the it_IT translation. 2019-05-04T12:51:21Z Carl Hetherington cth@carlh.net 2019-05-04T12:51:21Z urn:sha1:606b0a89db11cbbf81c24f805559be8af4ccb990 Updated fr_FR translation from Thierry Journet. 2019-05-04T00:20:34Z Carl Hetherington cth@carlh.net 2019-05-04T00:20:34Z urn:sha1:b5b6c538e4eabb9ab7ff91262e7885fd5e6bef25