dcpomatic/src/lib, branch snap DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=snap 2020-11-02T22:10:04Z Pass around JPEG2000 data as a shared_ptr and hence avoid a copy 2020-11-02T22:10:04Z Carl Hetherington cth@carlh.net 2020-11-01T22:51:19Z urn:sha1:2ea3a0d0e4066a166c0700bd1d53daa7f1c50dff of 4MB of data for every JPEG2000 frame we decode. Replace dcp::Data with dcp::ArrayData 2020-11-02T22:10:04Z Carl Hetherington cth@carlh.net 2020-11-01T22:40:01Z urn:sha1:6fa9748f382302fa88292b4219598bb81edc7bd0 Re-allow audio channel 15 to be mapped so that users can add 2020-11-02T22:08:01Z Carl Hetherington cth@carlh.net 2020-11-02T22:08:01Z urn:sha1:4cf45229bf55344e708fead769f694f13bacf39c their own sign language tracks until DoM supports them properly. 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.