summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-04-10 00:34:20 +0200
committerwm4 <wm4@nowhere>2020-04-10 00:34:20 +0200
commitc3b2e7ec07241a531e0ff376c19a0b6b50547224 (patch)
tree345cb66960ef5566f39518fdcbef9a1e606ac924
parent73e565dc0fdffc5eb8a1f9466a130867a7427183 (diff)
downloadmpv-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).
-rw-r--r--filters/filter.c9
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;