dcpomatic/src/lib/content.cc, branch j2k-passthru-information DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=j2k-passthru-information 2020-05-21T22:27:06Z Provide better information on what will happen to JPEG2000 content in inputs (part of #1471). 2020-05-21T22:27:06Z Carl Hetherington cth@carlh.net 2020-04-14T23:56:31Z urn:sha1:93a706be8996dadfd6d307a942f304d4948d6020 Round the length of video-containing content to the nearest frame. 2020-05-20T19:56:28Z Carl Hetherington cth@carlh.net 2020-05-20T18:20:47Z urn:sha1:48841aa4a4aa4704e1e054b294bac23996be6dd0 It seems reasonable, and is in the spirit of how positions are rounded to frame boundaries. It also fixes problems with unnecessary frames of black being created at the end of trimmed files, where there can be rounding-error-based confusion about where the content stops and the black begins. Try rounding length_after_trim. 2020-05-20T19:56:28Z Carl Hetherington cth@carlh.net 2020-05-20T12:36:16Z urn:sha1:bf0fb7f4f556946c18da151e468f237d9ca96094 Put Time types in dcpomatic namespace. 2019-05-10T22:43:55Z Carl Hetherington cth@carlh.net 2019-05-08T22:41:42Z urn:sha1:c4403784febdbdd42e9c32e67fadb147f11fe566 Fix case where the is FFmpegContent with 24fps video and 44.1kHz audio 2019-05-05T20:49:51Z Carl Hetherington cth@carlh.net 2019-05-05T20:49:51Z urn:sha1:870ab8d9295b9d4b6605e8876919d23379dc3a35 and a start trim of 6724000. With these numbers the start trim is on an integer video frame but halfway through an audio frame. Without this patch the trim would be "corrected" to 6724001, causing video frames to come out of the player at DCPTimes 0, 3999, 5999 etc. It's possible that Frame const position = time.frames_floor(_film->video_frame_rate()); in J2KEncoder::encode should be frames_round, which would also help with this, but that would be a much more risky patch. Make sure at least one position change event is emitted after 2019-04-26T21:31:24Z Carl Hetherington cth@carlh.net 2019-04-26T21:31:24Z urn:sha1:aafa1cc676b6bd4d333f0ff3a09e1effabf979c3 a timeline drag (with frequent=false), even if lots have been sent with frequent=true. Otherwise the code in the CHNAGE_TYPE_DONE branch of Butler::player_change never gets to seek (since frequent is true, it ignores the signal). Without the seek things go wrong. Believed to fix #1534. Try to fix some warnings. 2019-02-12T00:17:33Z Carl Hetherington cth@carlh.net 2019-02-12T00:17:33Z urn:sha1:6f856af55898f94b45e3be28aa4f7c962de8a398 Fix content properties (#1428). 2018-12-12T00:30:33Z Carl Hetherington cth@carlh.net 2018-12-12T00:30:33Z urn:sha1:3c414bf90d4cfcfe342c0b057b5134f72485fe32 Fix missed overload change. 2018-11-24T00:34:03Z Carl Hetherington cth@carlh.net 2018-11-24T00:34:03Z urn:sha1:08aed48d141f403a93640cf62d8be70161bd1d30 Remove Film pointer from clone(). 2018-11-21T22:25:43Z Carl Hetherington cth@carlh.net 2018-11-21T22:25:43Z urn:sha1:fe8251bb73765b459042b0fa841dae2d440487fd