dcpomatic/src/lib/player.cc, branch dkdm2 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=dkdm2 2020-04-23T13:48:19Z Nicer fix for 86102d30bf0aad89115bbeb3d8aaa2a27a0aa432 2020-04-23T13:48:19Z Carl Hetherington cth@carlh.net 2020-04-23T13:48:19Z urn:sha1:990f879d9af6300068af44c431b1a8e158e7f7a0 Add accessor for _playlist. 2020-04-23T13:00:56Z Carl Hetherington cth@carlh.net 2020-04-23T13:00:56Z urn:sha1:4b7185e4eda53534c4d71a1f31ba33ca3dd8dc8d Fix complete failure of preview/playback introduced in 2020-04-22T23:40:56Z Carl Hetherington cth@carlh.net 2020-04-22T23:40:56Z urn:sha1:86102d30bf0aad89115bbeb3d8aaa2a27a0aa432 4219d4b76c5cd5690b1f4fa0c248d93ced26d05a. Fix length of player output so it can be either the film's length or playlist's length, as appropriate. 2020-04-15T14:17:01Z Carl Hetherington cth@carlh.net 2020-04-15T14:17:01Z urn:sha1:4219d4b76c5cd5690b1f4fa0c248d93ced26d05a Fix Empty/Player behaviour when using a playlist that is not the same as the Film's. 2020-04-14T21:11:08Z Carl Hetherington cth@carlh.net 2020-04-14T21:11:08Z urn:sha1:67775a6d0d28131b98ae284c7be23d79ccdab685 Previously Empty would use the length of the film for its end point. Now it takes a Playlist (rather than a list of Pieces) and uses the length of that playlist for its end point. This fixes #1543, in which single-content audio analysis jobs would run for the whole length of the film, rather than the length of the content, producing strange graphs and incorrect progress reports. Ignore and report failures to decode frames during playback (#1593). 2020-04-14T20:16:27Z Carl Hetherington cth@carlh.net 2020-04-14T20:16:27Z urn:sha1:4ab86ef0295bcd6bb9297996a06006f371d22bae Make a new AudioBuffers constructor and use it to avoid some use of the more complicated copy_from. 2020-02-16T21:23:28Z Carl Hetherington cth@carlh.net 2020-02-16T21:23:28Z urn:sha1:915cecb8f2b4bb251e72bbcd6c41144b73f8bfd7 Fix crash with bitmapped subs that have zero width or height. 2020-02-06T09:34:30Z Carl Hetherington cth@carlh.net 2020-02-06T09:34:30Z urn:sha1:dec5ae11238495c64fffdab37f189d96aed7d636 Fix deadlock during content examination. 2020-01-28T22:23:47Z Carl Hetherington cth@carlh.net 2020-01-28T22:23:47Z urn:sha1:df48c75c38dd788835a93540aea243a2dac4bb10 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. Cache film length for Player::pass. 2020-01-25T00:47:00Z Carl Hetherington cth@carlh.net 2019-07-23T21:55:15Z urn:sha1:af0edaf7dcd36c367cb585c98e8413c5347a7386