f_async_queue: change reset behavior

Do not make resetting the "access" filters reset the queue itself. This
is more flexible, and will be used in a later commit.

Also, if the queue is not in the reset state while the input access
filter is reset, make it immediately request data again. This is more
consistent, because it'll enter the state it "should" be, rather when
the filter's process function is called at an (essentially) random point
in the future. This means the filter graph will resume work on its own
if the queue was not reset before filter reset.

This could affect the only current user of f_async_queue, the code for
the --vd-queue-enable/--ad-queue-enable feature in f_decoder_wrapper.
But it looks like this already uses it in a compatible way.

1 files changed, 6 insertions, 2 deletions

diff --git a/filters/f_async_queue.c b/filters/f_async_queue.c
index 696649f3d1..8aa2041dd9 100644
--- a/filters/f_async_queue.c
+++ b/filters/f_async_queue.c
@@ -248,7 +248,12 @@ static void reset(struct mp_filter *f)
     struct priv *p = f->priv;
     struct async_queue *q = p->q;
 
-    reset_queue(q);
+    pthread_mutex_lock(&q->lock);
+    // If the queue is in reading state, it is logical that it should request
+    // input immediately.
+    if (mp_pin_get_dir(f->pins[0]) == MP_PIN_IN && q->reading)
+        mp_filter_wakeup(f);
+    pthread_mutex_unlock(&q->lock);
 }
 
 // producer
@@ -266,7 +271,6 @@ static const struct mp_filter_info info_out = {
     .priv_size = sizeof(struct priv),
     .destroy = destroy,
     .process = process_out,
-    .reset = reset,
 };
 
 struct mp_filter *mp_async_queue_create_filter(struct mp_filter *parent,