dcpomatic/src/lib/ffmpeg_file_encoder.cc, branch zpos DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=zpos 2022-10-25T14:08:34Z Hopefully fix crash when the same frame is encoded twice. 2022-10-25T14:08:34Z Carl Hetherington cth@carlh.net 2022-10-24T18:37:02Z urn:sha1:e55b2b3a7eb05b3cc69411b133aeec9772420c83 Previously if some frame X was passed to the encoder twice I think this would happen: X1 written; X stored to _pending_images X2 written; _pending_images remains the same X1 encode finishes; X is discarded from _pending_images Data for X2 is read by the encoder but was just freed I think this might have resulted in intermittent crashes, which were fairly common in the 2.17.x branch with the test ffmpeg_encoder_prores_regression_1 But I didn't conclusively prove it. Fix failure to close exported files. 2022-07-10T21:31:57Z Carl Hetherington cth@carlh.net 2022-07-10T21:31:47Z urn:sha1:2f4fa5350bf59a08fa27dc4ea0c77e4bdad7dbd3 Add Prores 4444 support (#2263). 2022-06-12T20:32:34Z Carl Hetherington cth@carlh.net 2022-06-12T20:32:30Z urn:sha1:1c57df596882f15403ee97d01862f8b76cfb797b Rename PRORES -> PRORES_HQ 2022-06-12T19:44:53Z Carl Hetherington cth@carlh.net 2022-06-12T19:44:53Z urn:sha1:59209af1e2d73334ff7dfe6c7da465293dc24c0b Remove unused H246_PCM export code. 2022-06-06T21:10:58Z Carl Hetherington cth@carlh.net 2022-06-05T19:09:55Z urn:sha1:f7b6c0595fe13be3f4a10bcce88dd895b1111b57 Cleanup: use some more make_shared. 2022-05-26T07:46:21Z Carl Hetherington cth@carlh.net 2022-05-26T07:46:21Z urn:sha1:fb0e2ead59a442700c671270c7d57b5bffeaeab3 Use std::vector in AudioBuffers (#2236). 2022-04-20T20:12:46Z Carl Hetherington cth@carlh.net 2022-04-19T12:03:20Z urn:sha1:341ba1115b6285fec998901e50f9afb48bcaeeb6 Cleanup: remove unused parameter to PlayerVideo::force. 2022-04-07T20:13:11Z Carl Hetherington cth@carlh.net 2022-04-03T22:42:57Z urn:sha1:4f9314a311de379b105741273a15821da62a75cc Fix writing of planar audio to export buffers in some cases (#2223). 2022-03-30T20:59:05Z Carl Hetherington cth@carlh.net 2022-03-30T20:59:05Z urn:sha1:bd5c164496bcb86c41ae8ac42241a652ee3a1b14 Previously we did not take into account alignment padding that can exist with FLTP samples; each channel's block of samples can have a gap between. This doesn't happen with the normal 1024 sample blocks; only when flushing at the end, when we write shorter blocks. Not doing this right meant that we were passing uninitialised memory to aacenc which sometimes responded by returning an EINVAL due to one of its internal calculations returning a NaN. Various alignment tidying/fixups. 2021-09-27T11:41:46Z Carl Hetherington cth@carlh.net 2021-09-22T22:09:47Z urn:sha1:67ff55886b1ee86d99c2ea27d10c73b85b0504b7