From 06b29a4aefec332cf6f67bd44adf18757f951d64 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= Date: Sun, 28 Jun 2020 22:26:23 +0300 Subject: [PATCH] imagefreeze: Correctly answer the LATENCY query We never run as a live element, even if upstream is live, and never output any buffers with latency but immediately generate buffers as fast as we can according to the negotiated framerate. Passing the query upstream would proxy whatever mode of operation upstream has, which has nothing to do with how we produce buffers. Part-of: --- gst/imagefreeze/gstimagefreeze.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/gst/imagefreeze/gstimagefreeze.c b/gst/imagefreeze/gstimagefreeze.c index c6c6fd3daf..873ba4afa9 100644 --- a/gst/imagefreeze/gstimagefreeze.c +++ b/gst/imagefreeze/gstimagefreeze.c @@ -536,11 +536,10 @@ gst_image_freeze_src_query (GstPad * pad, GstObject * parent, GstQuery * query) break; } case GST_QUERY_LATENCY: - /* This will only return an accurate latency for the first buffer since - * all further buffers outputted by us are just copies of that one, and - * the latency is 0 in that case. However, latency changes are not - * straightforward, so let's do the conservative fix for now. */ - ret = gst_pad_query_default (pad, parent, query); + /* We never run as a live element, even if upstream is live, and never + * output any buffers with latency but immediately generate buffers as + * fast as we can according to the negotiated framerate */ + gst_query_set_latency (query, FALSE, 0, GST_CLOCK_TIME_NONE); break; default: ret = FALSE;