dcpomatic/src/lib/video_decoder.cc, branch v2.6.2 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.6.2 2015-10-26T09:37:29Z Reinstate subtitle speed-up patch 526fd6de4c80a7ac9614a1cb0209efff7b171cd5 but only for preview. 2015-10-26T09:37:29Z Carl Hetherington cth@carlh.net 2015-10-26T09:37:29Z urn:sha1:2e62b2c0de47fc8e5bcb5466b2876f9b23d2ae84 Revert "Avoid decoding other packets when looking for subs." 2015-10-23T15:12:14Z Carl Hetherington cth@carlh.net 2015-10-23T15:12:14Z urn: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: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. 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. 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 Logging improvements to allow prettier displays in the server GUI. 2015-10-09T12:45:12Z Carl Hetherington cth@carlh.net 2015-10-09T12:44:10Z urn:sha1:aeb835a18c8df347e0ed68fb24631b320abeb611 Lots of #include <iostream>s for Arch. 2015-09-14T21:49:36Z Carl Hetherington cth@carlh.net 2015-09-14T21:49:36Z urn:sha1:1858190cff2f960f3d1f0a5cc02c69da86088f5b Remove debug code. 2015-08-18T21:11:26Z Carl Hetherington cth@carlh.net 2015-08-18T21:11:26Z urn:sha1:8aeb1ed834bf6d61896b5478ba2c4529cb3fb706 Include tidying. 2015-08-18T17:04:49Z Carl Hetherington cth@carlh.net 2015-08-18T17:04:49Z urn:sha1:c2a97b6f83a32483817d02194a1e7c8d6828b0bb Do filling correctly for separate-content L/R 3D; before it was 2015-08-17T22:00:12Z Carl Hetherington cth@carlh.net 2015-08-17T22:00:12Z urn:sha1:d184945d41ea7d6e489621dc6492a93b5d91f7de trying to fill each individual piece of content as if it was providing both L and R frames.