dcpomatic/src/lib/subrip_decoder.cc, branch v2.4.14DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=v2.4.142015-10-26T09:37:29ZReinstate subtitle speed-up patch 526fd6de4c80a7ac9614a1cb0209efff7b171cd5 but only for preview.2015-10-26T09:37:29ZCarl Hetheringtoncth@carlh.net2015-10-26T09:37:29Zurn:sha1:2e62b2c0de47fc8e5bcb5466b2876f9b23d2ae84Revert "Avoid decoding other packets when looking for subs."2015-10-23T15:12:14ZCarl Hetheringtoncth@carlh.net2015-10-23T15:12:14Zurn:sha1:526fd6de4c80a7ac9614a1cb0209efff7b171cd5
This reverts commit 9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49.
It causes corruption in prophet_clip.xml for reasons that
are not yet known.
Avoid decoding other packets when looking for subs.2015-10-16T13:38:44ZCarl Hetheringtoncth@carlh.net2015-10-16T13:38:44Zurn:sha1:9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49
The "accumulation" of, for example, video data when we are looking
for audio data is an *optimisation* to reduce the number of seeks.
It should not be necessary for correctness (the output should be right
even if we never kept anything except what we were looking for).
Doing this accumulation is not always an optimisation; sometimes not
doing it is better. Avoiding it when going back for subtitles is one
of these cases.
Fix invalid Interop subtitle times in some cases.2015-10-15T08:13:33ZCarl Hetheringtoncth@carlh.net2015-10-15T08:13:33Zurn:sha1:6708d52b5c2ff9ccb6ee99f3b793d791bb95f26b
Use a much higher "timecode rate" (1000 rather than 24) when
representing the time of subtitles internally so that accuracy
is preserved and we don't end up rounding things up to give
out of range results.
Lots of #include <iostream>s for Arch.2015-09-14T21:49:36ZCarl Hetheringtoncth@carlh.net2015-09-14T21:49:36Zurn:sha1:1858190cff2f960f3d1f0a5cc02c69da86088f5bPass colour on when decoding.2015-07-02T12:39:19ZCarl Hetheringtoncth@carlh.net2015-07-02T12:39:19Zurn:sha1:88d2e9b659a7517c91a630c1cd67cc919c97d59aFix missing subtitles in some cases.2015-06-26T21:02:00ZCarl Hetheringtoncth@carlh.net2015-06-26T21:02:00Zurn:sha1:c8ff422a42eac30517a7acde57ab84e55449f4e4
We were passing subtitles back from decoders to SubtitleDecoder
using dcp::SubtitleStrings and relying on their storage of time
to know when the subtitles were. These times are quantised (by
the use of dcp::SubtitleString) and then compared with unquantised
times (kept as ContentTime) in the main checking loop in
SubtitleDecoder::get().
Fix this by storing periods as ContentTimePeriod as well as
in the dcp::SubtitleStrings.
No-op: remove all trailing whitespace.2015-06-21T00:15:32ZCarl Hetheringtoncth@carlh.net2015-06-21T00:15:32Zurn:sha1:e60bb3e51bd1508b149e6b8f6608f09b5196ae26Remove PassReason stuff.2015-06-12T12:47:35ZCarl Hetheringtoncth@carlh.net2015-06-12T12:47:35Zurn:sha1:bdbfd6b08856a445446bfd845f1c43109d184250
This feels wrong: it means that it is possible for FFmpegDecoder
to discard packets. I can't see how this is ok in all cases:
maybe we were lucky that it worked at all.
Fix horizontal positioning with .srt / burn-in (#488).2015-06-03T23:17:12ZCarl Hetheringtoncth@carlh.net2015-06-03T23:17:12Zurn:sha1:4f1751a9e43e515be773ee3871150f7beca325f5