dcpomatic/src/lib, branch benchmark DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=benchmark 2020-10-28T21:11:17Z WIP: time simple video view. 2020-10-28T21:11:17Z Carl Hetherington cth@carlh.net 2020-10-28T21:11:17Z urn:sha1:65355b63e3f3a9c475613acd4c0991e3687aeacc More benchmarks. 2020-10-28T16:28:25Z Carl Hetherington cth@carlh.net 2020-10-28T16:28:25Z urn:sha1:3132ed753a9e11d0f478d30620d14d7a6c478820 Add some comments. 2020-10-28T15:25:01Z Carl Hetherington cth@carlh.net 2020-10-28T15:25:01Z urn:sha1:22d8401d9eadb022e40380a324b5871f77a18158 Prevent import of directories as DCPs if they do not have an 2020-10-28T11:48:48Z Carl Hetherington cth@carlh.net 2020-10-28T11:48:48Z urn:sha1:2c74c1534cb563cab4c6c3225ced573619f6a647 ASSETMAP{,.xml} in the top level. This should avoid some confusion, as previously DoM would scan the whole directory tree looking for an ASSETMAP. It also prevents people adding a DCP-o-matic project to itself, which I believe is the cause of #1620. macOS / new boost build fixes. 2020-10-21T20:22:18Z Carl Hetherington cth@carlh.net 2020-10-21T07:23:12Z urn:sha1:1a7c50245309bb0b99001940b2203a267de942ca Fix deadlock when changing CPL in the player (#1827). 2020-10-17T20:23:12Z Carl Hetherington cth@carlh.net 2020-10-17T20:23:12Z urn:sha1:b33881c9ebe55084434bfea16ba050ad1ba6cb03 TextContent::set_dcp_track can end up requesting a view update, which involves calls to methods in Content which lock the Content::_mutex. Do these calls without a lock on that mutex held. Also, it looks like we would append to texts on every call to examine(). Fix that so that we replace the texts list on each examine() call. Don't crash if the first packet in a stream has AV_NOPTS_VALUE; 2020-10-14T19:24:57Z Carl Hetherington cth@carlh.net 2020-10-14T19:24:57Z urn:sha1:d7a3d94ec307a03ebe3fcf239ba991e9a3c1b8b8 instead, assume it should be at timestamp 0. Clear out _next_time when seeking, so out-of-date values don't 2020-10-14T19:23:36Z Carl Hetherington cth@carlh.net 2020-10-14T19:23:36Z urn:sha1:9a3df0a97b7962c00726447a75599e34c632cb2b hang around. Part of the fix for #1857. Fix errors when over-reading a "large" amount from FileGroups on 2020-10-13T16:51:11Z Carl Hetherington cth@carlh.net 2020-10-06T23:02:47Z urn:sha1:e5277d4042b896c4b50c694fba0f1afb47337f45 Windows. I haven't been able to find any conclusive explanation for why this stuff happens; https://stackoverflow.com/questions/7241168/safe-maximum-number-of-records-read-by-fread is one possible lead. Stop the Windows version of run_ffprobe manipulating the current working directory as tests rely on it. 2020-10-13T16:51:11Z Carl Hetherington cth@carlh.net 2020-10-06T19:37:46Z urn:sha1:a1d3a73736ff2a171ab1160dedf4faea40454bea