diff options
author | wm4 <wm4@nowhere> | 2020-03-05 21:38:58 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2020-03-05 22:00:50 +0100 |
commit | f06bf8c073fb851c49e65506b783c17e3d76bc0e (patch) | |
tree | 50edfa30f1c06ae67e49709ff0aa87bc04c445d5 /player/loadfile.c | |
parent | 443ed2cb56da94d748adcb3f7f3cd1b95a9121d7 (diff) | |
download | mpv-f06bf8c073fb851c49e65506b783c17e3d76bc0e.tar.bz2 mpv-f06bf8c073fb851c49e65506b783c17e3d76bc0e.tar.xz |
player: reduce impact of blocking filters
Some filters may block the playloop for a longer time. For example, if a
decoder fails to decode anything and somehow just discards packets, the
filter graph would run (in a blocking manner) until all packets are
read, which could take a longer time if the demuxer thread is fast
enough.
Make it exit every 100ms. That should at least give the user a chance to
stop playback.
Filtering could run on a different thread, but I don't see much value in
doing that in the general case. It would just waste a thread. Although
being able to use mp_filter_graph_interrupt() would be slightly nicer
than such a timeout mechanism. Decoding in particular can actually use a
separate thread (--vd-queue-enable), but again, this is not enabled by
default, because it just wastes a thread.
Like the previous f_decoder_wrapper commit, this is probably a sin.
Diffstat (limited to 'player/loadfile.c')
-rw-r--r-- | player/loadfile.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/player/loadfile.c b/player/loadfile.c index ae65d30caf..d2bdb47ccd 100644 --- a/player/loadfile.c +++ b/player/loadfile.c @@ -1399,6 +1399,7 @@ static void play_current_file(struct MPContext *mpctx) mpctx->seek = (struct seek_params){ 0 }; mpctx->filter_root = mp_filter_create_root(mpctx->global); mp_filter_root_set_wakeup_cb(mpctx->filter_root, mp_wakeup_core_cb, mpctx); + mp_filter_graph_set_max_run_time(mpctx->filter_root, 0.1); reset_playback_state(mpctx); |