dcpomatic/run/tests, branch v2.16.80 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.16.80 2024-04-18T12:00:07Z Missed update to private test repo version. 2024-04-18T12:00:07Z Carl Hetherington cth@carlh.net 2024-04-18T12:00:07Z urn:sha1:ab479fa7f20d84ea31ab35c0330f524ac0c48d21 The private test repo got some v2.18.x updates. 2024-03-19T22:02:32Z Carl Hetherington cth@carlh.net 2024-03-19T22:02:32Z urn:sha1:059ad8809b715ca7b84f769529e8a441e3f002f2 Don't emit subtitle images that have a zero dimension (#2743). 2024-02-03T08:57:25Z Carl Hetherington cth@carlh.net 2024-02-01T12:29:53Z urn:sha1:79ee0e5e79d8fb4a405d8b29827347d0243a17fe They cause problems later when trying to blend them into the image. Inspect most DCPs made during tests with ClairMeta (#76). 2024-01-15T11:44:53Z Carl Hetherington cth@carlh.net 2024-01-12T14:29:12Z urn:sha1:de1b4a967e6854782e88e83d48af74289977c8c3 Inspect most DCPs made during tests with dcp_inspect (#76). 2024-01-15T11:44:42Z Carl Hetherington cth@carlh.net 2024-01-11T15:24:38Z urn:sha1:a4a7d9ef34f2f083b0ba9e32e933ea5c64d2352d Missing PRIVATE_GIT update from previous. 2024-01-15T09:25:14Z Carl Hetherington cth@carlh.net 2024-01-15T09:25:14Z urn:sha1:7ea73fdcfa96aac86546b80b6e6c2edbdd524199 Support YUV422P9LE in alpha_blend() (#2671). 2023-12-09T15:40:06Z Carl Hetherington cth@carlh.net 2023-11-27T23:33:22Z urn:sha1:81dc813cda9ace9951e0aabb835bdfff098da2de Support alpha blending 64-bit RGB onto things. 2023-09-29T19:22:54Z Carl Hetherington cth@carlh.net 2023-09-28T20:18:34Z urn:sha1:a31c46c75ce5bdfbbdbe502f33ac675f3733f6b7 Fix errors with WAVs containing markers (#2617). 2023-09-28T22:57:58Z Carl Hetherington cth@carlh.net 2023-09-26T22:16:38Z urn:sha1:e67ce8ae4b9121bbcef2c1dcb61bdb5b9330ad78 I'm not 100% sure about this but they seem to end up giving audio packets with no channels and no frames. Here we handle such packets better. Set up packet duration correctly when encoding using FFmpeg (#2588). 2023-08-26T08:23:21Z Carl Hetherington cth@carlh.net 2023-08-24T13:44:32Z urn:sha1:d33678b8e64de795becd3fa336dbbb099c691f58 It seems strange that this is necessary (maybe I'm missing some other way that the packet duration is supposed to be set up). Without this, when the mov muxer writes the trak tags it uses an incorrect length value because the length value is calculated from trk->end_pts, which in turn is calculated from the last-seen pts + the duration of the last packet. If that packet is marked as length 0 the length of the track is 1 frame short, so the export is missing a frame.