dcpomatic, branch v2.4.12 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.4.12 2015-10-17T15:08:37Z Bump version 2015-10-17T15:08:37Z Carl Hetherington cth@carlh.net 2015-10-17T15:08:37Z urn:sha1:57f9f6d535661860990e74bcc3b00e80c8a705ed Supporter. 2015-10-17T13:22:09Z Carl Hetherington cth@carlh.net 2015-10-17T13:22:09Z urn:sha1:01230504a47f5a1c0da6c4f2ba0097dee62eccc3 Merge branch 'master' of ssh://git.carlh.net/home/carl/git/dcpomatic 2015-10-16T16:19:30Z Carl Hetherington cth@carlh.net 2015-10-16T16:19:30Z urn:sha1:bd709c1e98e7653dafe7dff302440a7890140c7d Remove the dreaded _decoded_video size assertion. 2015-10-16T14:08:48Z Carl Hetherington cth@carlh.net 2015-10-16T14:08:48Z urn: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. Update comment. 2015-10-16T14:05:29Z Carl Hetherington cth@carlh.net 2015-10-16T14:05:29Z urn:sha1:ad7ed1d8be8ce4cf55cbcadb3a6576e8c95f9877 Avoid decoding other packets when looking for subs. 2015-10-16T13:38:44Z Carl Hetherington cth@carlh.net 2015-10-16T13:38:44Z urn: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. Log to stdout in DCPOMATIC_DEBUG. 2015-10-15T11:03:30Z Carl Hetherington cth@carlh.net 2015-10-15T11:03:30Z urn:sha1:f0da433894308ed72b0dbdd116a30a8d659c33cc Bump libdcp. 2015-10-15T08:56:20Z Carl Hetherington cth@carlh.net 2015-10-15T08:56:20Z urn:sha1:e7811b466eff496db7f63842df2fa4a4410afe14 Use AV_ prefixes on some FFmpeg bits. 2015-10-15T08:14:43Z Carl Hetherington cth@carlh.net 2015-10-15T08:14:43Z urn:sha1:b67a3505b58ffd204ee1a2560be3026688be8f10 ChangeLog. 2015-10-15T08:14:37Z Carl Hetherington cth@carlh.net 2015-10-15T08:14:37Z urn:sha1:0165a71f3074233f03c868cce9b760e51cc10ff5