diff options
author | wm4 <wm4@nowhere> | 2015-08-20 15:25:32 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2015-08-20 15:25:32 +0200 |
commit | 147f4956d3ecc38dab4932bbdc8ed532664f0dfd (patch) | |
tree | 8e3491ea527e810bfedc238bc07b00efc369024e | |
parent | 895c8801a2c9915784ee043cb805ede2da9b11c9 (diff) | |
download | mpv-147f4956d3ecc38dab4932bbdc8ed532664f0dfd.tar.bz2 mpv-147f4956d3ecc38dab4932bbdc8ed532664f0dfd.tar.xz |
player: deliver IDLE event after uninitializing state
A client API user might count on the fact that audio and video outputs
have already been uninitialized. (They remain uninitialized before
entering idle mode in order to allow smooth transition to the next
playlist entry.) Since event delivery is asynchronous, this has to
happen after actually doing the uninitialization, or the client will
essentially run into a race condition.
-rw-r--r-- | player/playloop.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/player/playloop.c b/player/playloop.c index b361f7c11c..2ab5f39dac 100644 --- a/player/playloop.c +++ b/player/playloop.c @@ -1075,10 +1075,10 @@ void idle_loop(struct MPContext *mpctx) && mpctx->stop_play != PT_QUIT) { if (need_reinit) { - mp_notify(mpctx, MPV_EVENT_IDLE, NULL); uninit_audio_out(mpctx); handle_force_window(mpctx, true); mpctx->sleeptime = 0; + mp_notify(mpctx, MPV_EVENT_IDLE, NULL); need_reinit = false; } mp_idle(mpctx); |