dcpomatic/src/lib/video_decoder.cc, branch v2.6.28DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=v2.6.282016-01-27T23:09:20ZPossibly better version of d217a16d41dd71c921fa2155e068df7cca11f457.2016-01-27T23:09:20ZCarl Hetheringtoncth@carlh.net2016-01-27T23:09:20Zurn:sha1:13aceac46acc966ffddcbc08982e8090415625f3
Don't stop returning stuff from get_video when there are frames
left in _decoded_video.
Merge branch 'master' of ssh://git.carlh.net/home/carl/git/dcpomatic2016-01-24T23:53:22ZCarl Hetheringtoncth@carlh.net2016-01-24T23:53:22Zurn:sha1:aebfa24afe42d80693df66318e5d2818ebf5989bStop trying to get frames from a video source when an attempt2016-01-24T23:40:32ZCarl Hetheringtoncth@carlh.net2016-01-24T23:40:32Zurn:sha1:d217a16d41dd71c921fa2155e068df7cca11f457
to get an earlier frame has already failed because the decoder
said it has no more data. Before this the VideoDecoder would
repeatedly seek to try to get a frame which does not exist.
This happens when the header of a file is wrong, it would seem;
in the file that triggered the bug the header (as read by DoM or ffprobe)
has a length of 137275 frames but the last frame in the file
(according to DoM or ffprobe -show_frames) is 136207 (44.5s earlier).
Missing but inconsequential break.2016-01-24T22:57:36ZCarl Hetheringtoncth@carlh.net2016-01-24T22:57:36Zurn:sha1:468887f4c0994a58032f27018b622021131d1e8cReduce variable scope slightly.2016-01-24T22:11:41ZCarl Hetheringtoncth@carlh.net2016-01-24T22:11:41Zurn:sha1:d3d503bc046c1c317951d239e7cdb41e8f695b66Reinstate 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.
Remove the dreaded _decoded_video size assertion.2015-10-16T14:08:48ZCarl Hetheringtoncth@carlh.net2015-10-16T14:08:48Zurn:sha1:f09e6545efa4c5ca816e89e28a287bc6ab1ee50b
I am reasonably convinced that the accumulation of _decoded_video
is an optimisation rather than being required for correctness,
so it's no problem to throw frames away as the code will just
get them back again if and when it needs them.
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.
Use AV_ prefixes on some FFmpeg bits.2015-10-15T08:14:43ZCarl Hetheringtoncth@carlh.net2015-10-15T08:14:43Zurn:sha1:b67a3505b58ffd204ee1a2560be3026688be8f10