DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.15.154 2021-06-04T22:44:48Z 2021-06-04T22:44:48Z Carl Hetherington cth@carlh.net 2021-06-04T17:46:47Z urn:sha1:a68896458c2779381709950c8a2e48ef0a3b5364 2021-06-04T22:01:03Z Carl Hetherington cth@carlh.net 2021-06-04T22:01:03Z urn:sha1:3c5a2f73afa9a3a5324b0345ffa9642ee474598d 2021-06-04T20:31:07Z Carl Hetherington cth@carlh.net 2021-06-03T20:55:44Z urn:sha1:9f4cb3b340376d93be39dc97c2e0c631e9cf73c4 The comments discuss this in a bit more depth, but basically we see errors from avcodec_send_packet after seek. ffplay etc. seem basically to ignore all errors from avcodec_send_packet, and I can't find a "proper" fix, so here's a half-way house hack: ignore some errors after seek. Nasty. 2021-06-04T20:30:25Z Carl Hetherington cth@carlh.net 2021-06-04T20:30:25Z urn:sha1:a498b8819ab431ecc2aac058b1aadb9e15d396ac 2021-06-03T20:46:53Z Carl Hetherington cth@carlh.net 2021-06-03T20:46:53Z urn:sha1:881e5de77401086265c5d901c7bde10d35d50231 2021-06-03T19:12:06Z Carl Hetherington cth@carlh.net 2021-06-03T19:12:06Z urn:sha1:4b23e0aa4bf557756a0ad5098239a4fca7e32bab Also fixes problems with invisible subtitles from binary STL files with weird line numbers. 2021-06-03T18:40:16Z Carl Hetherington cth@carlh.net 2021-06-03T18:40:16Z urn:sha1:ab3be5fa1893bf1756627e1646b065c41e69336a The test fails if we don't do this; it doesn't really seem 100% convincing but we are already doing this for audio. 2021-06-03T13:31:16Z Carl Hetherington cth@carlh.net 2021-06-03T13:31:16Z urn:sha1:56062a84cca360881bfa3bd2b2254d451223d775 2021-06-02T08:27:58Z Carl Hetherington cth@carlh.net 2021-05-31T13:45:51Z urn:sha1:d077ad2b75c45b5abea465f5e8bc4a3850a172f3 c432ef98c4cf3b2bda32734983eec3b42b8c3d1e completely broke the relinking of libraries using install_name_tool by only doing it for the x86_64 part of the binaries. This commit fixes that, and also does some tidy up that happened while trying to debug the error. The main cleanup is that --deep is no longer used with codesign, rather we sign all the executables ourselves manually. Various Apple forums suggest that --deep is a Bad Idea for reasons that aren't really clear. For reference, after spending days trying to debug the Gatekeeper refusal to start DoM the way to reveal the problem was: 1. start a clean VM (there are caches everywhere, so once a failure has happened you are even less likely to get any useful logging on the second failure). 2. open "Console" on macOS; logs are written to un-greppable places so you have to use this to see everything. 3. click "start streaming"; I don't know if this step is necessary. 4. put a search term in the search box (e.g. "dcp" for this) 5. start the thing that is not working. And remember that otool without `-arch` on a fat binary will only really operate / look at the first? native? architecture, so if you have an x86_64/arm64 binary and the arm64 parts are wrong you won't see anything about that with `otool -L`, only with `otool -arch arm64 -L` 2021-06-01T23:45:29Z Carl Hetherington cth@carlh.net 2021-06-01T23:45:29Z urn:sha1:fc00f4d30f4b798dd21964d1e9931b94c09f5c06