diff options
author | wm4 <wm4@nowhere> | 2020-04-10 00:34:20 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2020-04-10 00:34:20 +0200 |
commit | c3b2e7ec07241a531e0ff376c19a0b6b50547224 (patch) | |
tree | 345cb66960ef5566f39518fdcbef9a1e606ac924 /filters | |
parent | 73e565dc0fdffc5eb8a1f9466a130867a7427183 (diff) | |
download | mpv-c3b2e7ec07241a531e0ff376c19a0b6b50547224.tar.bz2 mpv-c3b2e7ec07241a531e0ff376c19a0b6b50547224.tar.xz |
filter: process asynchronous wakeups during filtering
If a filter receives an asynchronous wakeup during filtering, then
process newly pending filters resulting from that as well, before
returning to the user. Might possibly skip some redundant playloop
cycles.
There is an explicit comment in the code about how this shouldn't be
done, but I think it makes no sense. Filters have no business trying to
interrupt the mainloop, and mp_filter_graph_interrupt() provides a
proper mechanism to do this (though intended to be used by the filter
user, not filters).
Diffstat (limited to 'filters')
-rw-r--r-- | filters/filter.c | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/filters/filter.c b/filters/filter.c index a60df10616..9941ae4b95 100644 --- a/filters/filter.c +++ b/filters/filter.c @@ -194,8 +194,6 @@ bool mp_filter_graph_run(struct mp_filter *filter) r->filtering = true; - // Note: some filters may call mp_filter_wakeup() from process on themselves - // to queue a wakeup again later. So do not call this in the loop. flush_async_notifications(r); while (1) { @@ -210,8 +208,11 @@ bool mp_filter_graph_run(struct mp_filter *filter) break; } - if (!r->num_pending) - break; + if (!r->num_pending) { + flush_async_notifications(r); + if (!r->num_pending) + break; + } struct mp_filter *next = r->pending[r->num_pending - 1]; r->num_pending -= 1; |