dcpomatic/src/lib/player.cc, branch masterDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=master2020-02-16T20:25:49ZPotential fix for #1568; we calculate the remaining DCPTime but2020-02-16T20:25:49ZCarl Hetheringtoncth@carlh.net2019-05-26T01:58:17Zurn:sha1:ac112cdc14b0f600ac1c2d4e24f8b19eea132f54
then convert it back to resampled content frames using the DCP
rate rather than the resampled content rate, which seems wrong.
If we want to go from metric time to frames we surely have to use
the frame rate of the thing we are working with (not the frame rate
which that thing will be played back at).
Backported from 26c62598730d1d32333bfab0d5f463b90d26ee4d in v2.15.x.
Fix deadlock during content examination.2020-02-16T20:23:42ZCarl Hetheringtoncth@carlh.net2020-01-28T22:23:47Zurn:sha1:4b38c8f429407ec09609236fc7b2349459536571
Before this fix, the following situation could happen in threads
A and B:
A: Some DONE signal happens; this triggers setup_pieces which
takes a lock on the player mutex.
B: FFmpegContent::examine takes a lock on the content mutex.
B: FFmpegContent::examine adds a stream
B: That causes STREAMS PENDING to be emitted.
B: This tries to take a lock on the player mutex so it can update _suspended
A: setup_pieces tries to access some content information, hence
tries to take a lock on the content mutex.
Now B is holding the CL and awaiting the PL and A is holding
the PL and awaiting the CL.
It feels like the root cause of this is that while setup_pieces
is happening another change (which would itself cause setup_pieces)
is announced, and this isn't dealt with properly.
There are two steps here; _suspended is protected with an atomic
rather than using _mutex, and also it can cope with being updated
recursively.
Backported from df48c75c38dd788835a93540aea243a2dac4bb10 in v2.15.x
Fix crash with bitmapped subs that have zero width or height.2020-02-06T09:35:54ZCarl Hetheringtoncth@carlh.net2020-02-06T09:34:30Zurn:sha1:9482a41238c370e093c896145b844dac0b221345
Back-ported from dec5ae11238495c64fffdab37f189d96aed7d636 in v2.15.x.
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 comment.2019-11-11T13:13:41ZCarl Hetheringtoncth@carlh.net2019-11-11T13:13:41Zurn:sha1:dc18bbe7fb73ceaa169ff27e56d00bf32b509519Increase fudge factor at the boundary between audio signal and silence.2019-11-11T13:12:33ZCarl Hetheringtoncth@carlh.net2019-11-01T10:25:20Zurn:sha1:b1f03ef090dd57d8d33b814184583865a92c1d48Add a warning log when an assertion gets hit.2019-09-19T22:28:24ZCarl Hetheringtoncth@carlh.net2019-09-19T22:11:25Zurn:sha1:730a0a42ae0a4428693c3b560044c777751939ceFix errors when adding reels containing audio after referenced reels (#1528).2019-04-17T15:52:02ZCarl Hetheringtoncth@carlh.net2019-04-17T15:52:02Zurn:sha1:5b68916d71fbaac6c84ffc37e98d4ad42d450961Another attempt to fix build.2019-03-23T08:44:58ZCarl Hetheringtoncth@carlh.net2019-03-23T08:44:58Zurn:sha1:a95e78ea9d4c39f05fc8f7b58141a6a5bdc91ad6Try to fix Windows build.2019-03-23T07:52:10ZCarl Hetheringtoncth@carlh.net2019-03-23T07:52:10Zurn:sha1:f0e9267d0839c1eb3e716f6e73a5f1b37d0bad12