DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.10.5-test 2016-12-08T11:23:58Z 2016-12-08T11:23:58Z Carl Hetherington cth@carlh.net 2016-12-08T11:23:58Z urn:sha1:a28ef704adf8c5bfa45b3d6285f741af64758ceb This fixes the failure to keep track of the `position' of each stream of a multi-stream file. It also tidies things up a bit. 2016-11-21T10:35:48Z Carl Hetherington cth@carlh.net 2016-11-21T10:35:48Z urn:sha1:5b2b4ad4477561120973be08ae9299f21f5533a0 2016-11-20T23:58:51Z Carl Hetherington cth@carlh.net 2016-11-20T23:58:51Z urn:sha1:878e19aabf2278828a3c9b518e0804b2cef0c01e 2016-11-19T20:40:36Z Carl Hetherington cth@carlh.net 2016-11-19T20:40:36Z urn:sha1:f113b2aaca7a65f7b37e12a7d9f3f99e2d834e81 2016-11-19T00:51:05Z Carl Hetherington cth@carlh.net 2016-11-19T00:31:37Z urn:sha1:24e890682b3f2aa211277ad8b6b3591f2026d4be 2016-11-17T01:06:31Z Carl Hetherington cth@carlh.net 2016-10-07T15:22:38Z urn:sha1:97d39f46795af78b84d5f7bc9118a188f2864781 Before this commit, decoders try to guess whether they should request a seek based on what they have in their buffers. This seems reasonable for video and audio, which will always (I think) have some data lying around to give an indication of where their parent decoders are in the timeline. It doesn't work so well for subtitles, as the storage of subs is cleared out based on time (+/- 5s of "now") so there is a good chance that the storage will be empty. This gives the subtitle decoder no chance of knowing where its parent is, so it's very likely to seek. This commit asks the parent decoder to seek if it wants to, and it decides based on a knowledge of roughly where it is in the timeline. Hence the sub-decoders just see if they have got the data that is being requested, and if not they suggest to the parent that it might like to seek. They then start calling pass(). Hence the parent should only seek if some calls to pass() are not going to elicit the required data in a reasonable time. 2016-08-15T13:56:42Z Carl Hetherington cth@carlh.net 2016-08-15T13:56:42Z urn:sha1:8e96f8c1677146d224438ec040982532879d6c34 2016-07-08T20:13:06Z Carl Hetherington cth@carlh.net 2016-07-08T20:13:06Z urn:sha1:02cc8c7680381c123a31c23a43f6b34a04c2115a This fixes audio-only content when the first-emitted audio is not at time zero. This used to cause a seek which is not possible with audio-only. This commit removes the unnecessary seek which was due to missing silent-padding of the first-emitted audio. 2016-07-08T00:50:29Z Carl Hetherington cth@carlh.net 2016-07-05T08:49:00Z urn:sha1:d4014e6e3de7cdf8168a82621cf6a5a6d47379c8 Before this commit, an audio delay of -110ms on a test project would result in a seek on every video and audio fetch. This commit does two things to fix that: 1. Don't discard audio data that arrives with a timestamp before the last seek time. In the case that we are fixing we had the following sequence: - video seeks to some frame F - this causes audio data to arrive a little before F - this audio data is discarded - and audio get happens just after F - the audio code thinks it must seek rather than just pass()ing since it has no data If we keep the audio data from before the seek our _decoded will be much closer to the audio request, so a pass() is more likely to happen. 2. Extend the length of time that we will happily pass() for rather than seeking when looking for audio data. Seeking is really bad so we can tolerate quite long times here. The sensible length of this value should probably be investigated as the one in this commit is a finger-in-the-air guess. 2016-06-22T00:47:28Z Carl Hetherington cth@carlh.net 2016-06-22T00:47:28Z urn:sha1:76f83b97c401c24b3c93baee0665e84be05f43ea