path: root/
diff options
authorwm4 <wm4@nowhere>2020-02-29 21:13:56 +0100
committerwm4 <wm4@nowhere>2020-02-29 21:52:00 +0100
commit485f335b697069a04516beaa4e3cc118d92789e5 (patch)
tree2e2392f21bb1e928ae7f8447b3ab41d42f060754 /
parentf29623786b871807a663ce922d9afbf0d716a387 (diff)
filter: add async queue filter
This is supposed to enable communication between filter graphs on separate threads. Having multiple threads makes only sense if they can run concurrently with each other, which requires such an asynchronous queue as a building block. (Probably.) The basic idea is that you have two independent filters, which can be each part of separate filter graphs, but which communicate into one direction with an explicit queue. This is rather similar to unix pipes. Just like unix pipes, the queue is limited in size, so that still some data flow control enforced, and runaway memory usage is avoided. This implementation is pretty dumb. In theory, you could avoid avoid waking up the filter graphs in quite a lot of situations. For example, you don't need to wake up the consumer filter if there are already frames queued. Also, you could add "watermarks" that set a threshold at which producer or consumer should be woken up to produce/consume more frames (this would generally serve to "batch" multiple frames at once, instead of performing high-frequency wakeups). But this is hard, so the code is dumb. (I just deleted all related code when I still got situations where wakeups were lost.) This is actually salvaged and modified from a much older branch I had lying around. It will be used in the next commit.
Diffstat (limited to '')
1 files changed, 1 insertions, 0 deletions
diff --git a/ b/
index aa41aa06ea..f80fb08a83 100644
--- a/
+++ b/
@@ -300,6 +300,7 @@ def build(ctx):
( "demux/packet.c" ),
( "demux/timeline.c" ),
+ ( "filters/f_async_queue.c" ),
( "filters/f_autoconvert.c" ),
( "filters/f_auto_filters.c" ),
( "filters/f_decoder_wrapper.c" ),