dcpomatic, branch v2.15.41 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.15.41 2020-01-10T14:20:17Z Don't truncate active_video_frame_rate to an int otherwise setting fade on non-integer-rate sources behaves oddly. 2020-01-10T14:20:17Z Carl Hetherington cth@carlh.net 2020-01-10T14:20:17Z urn:sha1:a972af6dcbdb0b8a1c5386d34a0cea2c12738a67 Fix deadlock. 2020-01-10T14:13:35Z Carl Hetherington cth@carlh.net 2020-01-10T14:13:35Z urn:sha1:ba983cf47c98be684ee6ac1560f55364016b16f8 Give DCPDecoder its own ::position which just returns its internal 2020-01-10T00:01:03Z Carl Hetherington cth@carlh.net 2020-01-09T23:52:20Z urn:sha1:efc3486f2acf36bd0dc7b5528e7b3110ea8c4afe _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. Update text panel 'why not' note when film's standard is changed. 2020-01-09T22:25:18Z Carl Hetherington cth@carlh.net 2020-01-09T22:22:22Z urn:sha1:75e31f6b26b2c0775c51fe83938aab7ccbb2684b Forward-ported from e8582393bd1367fff36bae8e053d799073d8b2ed in master. Make the 'why not' messages for VF a bit clearer. 2020-01-09T22:24:35Z Carl Hetherington cth@carlh.net 2020-01-09T22:24:32Z urn:sha1:886e0f9d08a241bef5baf328beb08a0d6996ae14 Before it sounded like just because we couldn't refer to (e.g.) the audio we couldn't refer to any part of the DCP. Merge a set of changes which run the OpenGL video updates in a separate 2020-01-08T21:22:01Z Carl Hetherington cth@carlh.net 2020-01-08T21:22:01Z urn:sha1:579d18cb7770efe2da03afaf6a33faaf624119e3 thread, hopefully making things more elegant and robust. First version of player stress-test management script. 2020-01-08T20:56:47Z Carl Hetherington cth@carlh.net 2019-12-11T23:45:16Z urn:sha1:23590dc430e4ef2351209e30a26ba04fecca2872 Some comments. 2020-01-08T20:56:47Z Carl Hetherington cth@carlh.net 2019-11-25T23:37:42Z urn:sha1:b1589146e73ad97d3f29e9d5cafe61e5424796a4 Some simple-video-view tidy-ups. 2020-01-08T20:56:47Z Carl Hetherington cth@carlh.net 2019-11-25T23:33:46Z urn:sha1:c967096b5061e4bbb3a275d4daf04a2b9c084468 Fix problems when starting to play after a seek, if the start 2020-01-08T20:56:47Z Carl Hetherington cth@carlh.net 2019-11-25T23:32:37Z urn:sha1:0b21bfba60be812a5d04cc5c10868e04b5579404 of playback happens while we are awaiting an idle handler to go through to update the view after the seek. If this idle handler has not gone through the viewer will report an incorrect position, which is used by the FilmViewer to start the audio stream at the wrong time.