| Age | Commit message (Collapse) | Author |
|---|
|
Adapted from d23f55d8cd73adda823d0a2fcabc129b8845a81 in master.
|
|
assertion failures.
Before this, it was possible for J2KEncoder::terminate_threads()
to finish without terminating all threads if the thread _running_
terminate_threads() was itself interrupt()ed.
This is because the thread_group::join_all() in terminate_threads()
is an interruption point, so it was possible it not to complete
but instead to throw interrupted_exception. Then the owning
J2KEncoder would be torn down but the threads would still be running,
causing use-after-frees.
This commit adds some boost::this_thread::disable_interruption
objects to ensure that the owning thread is not interrupted while
it is being destroyed.
Also tidy up code that does this stuff, assuming that it's safe
to not call thread::joinable but instead do
thread.interrupt();
try {
thread.join();
} catch (...) {}
|
|
|
|
|
|
the whole of ::audio. Otherwise changes to pending seeks can be
mixed up with audio being put into the ringbuffer.
|
|
many content changes in an idle handler, rather than blocking
the UI update until the seek and image redisplay have finished.
|
|
of the state of frequent, so Butler::player_change must always seek
regardless of the state of frequent. Otherwise setup_pieces() results
in the next pass() output being at position 0, which causes problems
when the audio from that output is pushed into the audio ring buffers.
|
|
|
|
|
|
|
|
- some player_change; _awaiting is set
- regular seek occurs (perhaps to a time much earlier than _awaiting)
- another player_change occurs; player_change handler wrongly seeks back to _awaiting
May help with #1505.
|
|
|
|
|
|
|
|
|
|
|
|
a slight performance improvement for playback.
|
|
|
|
This is important for audio. _audio.put() must be called with
sequential data, so if you're going to discard audio (as was
happening when _suspended) you need to clear _audio before
put()ting any more.
This happens with seek; when _pending_seek_position is set
_audio is cleared and then nothing more is added until the
seek is done.
_suspended may be set and then reset with no change having
happened (type _CANCELLED) so I think you have to keep storing
data in this case. It will be discarded when the seek comes
around after a _DONE change.
|
|
while it's suspended. Then make the GUI follow that suggestion.
Should
|
|
|
|
Fix player_change to summon the butler if _suspended is changed, and
ensure that the butler's Player::Change handler is the first to be
called so that suspension is sorted out before any other
Player::Change handlers might call get_video().
This is to prevent the sequence
1. player change-pending emitted
2. hence butler suspended -> 1
3. player change-done emitted
4. first handler is something which calls get_video()
5. get_video() awaits video which will never arrive because the butler
is suspended.
Here there is a pending change-done signal to butler. Ensuring this
arrives before the handler which calls get_video() sorts it out.
|
|
|
|
this treatment to anything that caused Player::setup_pieces. This should
fix out-of-sequence Player emissions caused by setup_pieces being called
by one thread while the butler is calling pass().
|
|
between Player::_suspended being set to false and the the butler
requesting a seek, during which the butler may call pass().
|
|
and the butler.
Here we signal both before and after a change in content. Before,
the player disables itself so that any pass()/seek() will be no-ops.
After, the player rebuilds its pieces and the butler re-seeks to
get back to where it was before the change.
|
|
|
|
|
|
You can't introduce the butler (so that the player is ahead of time)
and then ask the player what should be in the frame that is being
displayed "now"; the player will already have moved on.
|
|
|
|
audio in FilmViewer. This should help with the case where lots
of video frames are rapidly discarded when they are late but the
corresponding audio is not, hence audio buffers get overfilled.
|
|
when moving content (or otherwise changing the playlist) while playing.
This commit refills the butler when things change in certain ways,
and improves locking to cope with Player methods being called from
the GUI and butler threads at the same time.
|
|
|
|
seek() and pass() may be called from the Butler thread
ad the same time as other Player methods are called from
the GUI thread (by FilmViewer and ClosedCaptionViewDialog).
|
|
|
|
|
|
when playing DCPs.
Before, the lock was only held to check _pending_seek_position.
With that arrangement, this sequence was possible:
1. video arrives, check _pending_seek_position, decide it's ok, release lock
2. Butler::seek called, sets _pending_seek_position, clears _video
3. video that arrived in #1 is put into _video by ::video()
4. that video is given to an awaiting get_video() call.
This clearly subverts the attempts not to accept new video data while
a seek is pending.
|
|
|
|
|
|
|
|
readahead quite a bit. This in turn reduces the maximum butler memory
usage as it will keep getting audio (and hence video) until the
minimum audio readahead is hit.
|
|
|
|
|
|
|
|
|
|
Other layers will seek as appropriate, we shouldn't fight them I don't think.
|
|
|
|
|
|
|
|
|
