dcpomatic/src/lib, branch debug/shaneDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=debug%2Fshane2020-01-17T22:34:58ZDebug.2020-01-17T22:34:58ZCarl Hetheringtoncth@carlh.net2020-01-17T22:34:58Zurn:sha1:ffb3cf8bfe397c87d0e797eb8732aa6b1f6c5091Merge branch 'master' of ssh://git.carlh.net/home/carl/git/dcpomatic2020-01-16T22:41:51ZCarl Hetheringtoncth@carlh.net2020-01-16T22:41:51Zurn:sha1:07397e3aa8fff4613cea0b833ca8db8e0f60844bMake FileError say what path the problem was with.2020-01-16T15:41:54ZCarl Hetheringtoncth@carlh.net2020-01-16T15:41:19Zurn:sha1:94ee305348f7d3eb548fd44ca4aa1c57645056b1
Backported from 2ba5edb6761dbb14e4906200cb4e57c4180541ff in master.
Add some PT-style names to the guesswork on which channel a particular sound file belongs to.2020-01-14T21:55:06ZCarl Hetheringtoncth@carlh.net2020-01-14T21:53:38Zurn:sha1:df62a2d137400c6c6286675f30597b91203e6374
Backported from 0dca360f831aa51a4c0a33caa18e78c07391f3b7 in v2.15.x.
Give DCPDecoder its own ::position which just returns its internal2020-01-09T23:52:20ZCarl Hetheringtoncth@carlh.net2020-01-09T23:52:20Zurn:sha1:4285355ff2bec853924647f0523d121860fe64e3
_next time.
This is important because Decoder::position does the wrong thing
with DCPs in the following case.
1. DCPDecoder emits a subtitle event (start/stop) at time t.
2. There follows a long time T with no subtitle events. During
this time the DCPDecoder's position is reported as t (since
TextDecoder notes its position as the time of the last thing
it emitted --- which is all it reasonably can do, I think).
3. During this T the DCPDecoder may be incorrectly pass()ed because
its position is reported as earlier than it really is; this results
in video/audio being emitted by the DCPDecoder but other contemporary
sources may not be pass()ed.
The upshot of this can be that no audio is emitted, as a contemporary audio
source is not pass()ed and hence the merger is waiting for audio that will
take a long time to come. When the butler is running this can result in
audio underruns as the video buffers overflow with no sign of any audio.
It is also simpler this way; DCPDecoder was already maintaining the required
information.
Extend the amount of allowed disagreement between the audio2020-01-07T12:30:56ZCarl Hetheringtoncth@carlh.net2020-01-07T12:30:56Zurn:sha1:0e86a5da67451dfc6120406e5282fc786de6e248
coming from the content and the calculated periods of silence.
It sees that there is some scope for disagreements here when
trim start/end times are rounded to frame boundaries.
Fixes #1708.
Fix failure to save screen notes when making a new one (github bug #6).2020-01-03T01:29:48ZCarl Hetheringtoncth@carlh.net2020-01-03T01:29:24Zurn:sha1:9ef42119694384a024104e9456e01d3c0e7bca2fRemove our forcing of analyzeduration and probesize as they seem to2019-12-19T22:56:49ZCarl Hetheringtoncth@carlh.net2019-12-19T22:56:49Zurn:sha1:715d87a4cf9e4697a2f67881776c19c4ce8af581
cause weird problems when scanning some files. The unit test case
added here is a case in point: before this patch one
stream reported an incorrect channel count and sample rate.
It's a bit worrying as these parameters have been in DoM for many years,
but perhaps they have become unnecessary / harmful with changes to FFmpeg.
Flush audio decoder when a DCPDecoder finishes so that2019-12-16T23:00:12ZCarl Hetheringtoncth@carlh.net2019-12-16T23:00:12Zurn:sha1:1444299fa4582fc65c5237edd6c115921f20f872
resamplers are emptied and hence we don't lose any
samples. Fixes #1691.
Stop empty Font IDs in imported DCP subtitles making it into the2019-12-15T22:35:03ZCarl Hetheringtoncth@carlh.net2019-12-15T22:35:03Zurn:sha1:07f451e01f82793904482f55c5a89163c6bb8e44
output DCP (#1689).
Back-ported from d8d4225a3e488cf78438b80938aa18fd07d30a06 in v2.15.x