summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2015-08-20 15:25:32 +0200
committerwm4 <wm4@nowhere>2015-08-20 15:25:32 +0200
commit147f4956d3ecc38dab4932bbdc8ed532664f0dfd (patch)
tree8e3491ea527e810bfedc238bc07b00efc369024e
parent895c8801a2c9915784ee043cb805ede2da9b11c9 (diff)
downloadmpv-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.c2
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);