GNOME Bugzilla – Bug 627256
failure querying latency for high latency?
Last modified: 2010-08-19 13:14:37 UTC
The below pipeline works with min-threshold-time=1000000000=1s (on 0 less). Queue also handles min_threshold.time - now sure what is leading to that error then. $ GST_DEBUG="*:2" gst-launch v4l2src ! video/x-raw-yuv, width=640, height=480 ! queue min-threshold-time=10000000000 ! xvimagesink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... 0:00:00.170192934 24784 0x8c05018 WARN bin gstbin.c:2330:gst_bin_do_latency_func:<pipeline0> failed to query latency New clock: GstSystemClock 0:00:00.977090034 24784 0xb6703850 WARN bin gstbin.c:2312:gst_bin_do_latency_func:<pipeline0> warning: Impossible to configure latency: max 0:00:01.066666666 < min 0:00:10.033333333. Add queues or other buffering elements. WARNING: from element /GstPipeline:pipeline0: Internal GStreamer error: clock problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstbin.c(2312): gst_bin_do_latency_func (): /GstPipeline:pipeline0: Impossible to configure latency: max 0:00:01.066666666 < min 0:00:10.033333333. Add queues or other buffering elements.
In this case you ask the queue to only start outputting data when there is more than 10s of data in it. This means that the minimun latency is at least 10s. Together with the max size of the queue, that is by default set to 1s, this creates the impossible situation you see here. The fact that this pipeline actually prerolls and somewhat runs is because it eventually hits the other byte and buffer limits of the queue.
Thanks! this works perfect. gst-launch v4l2src ! video/x-raw-yuv, width=640, height=480 ! queue min-threshold-time=10000000000 max-size-time=0 max-size-bytes=0 ! xvimagesink
and now half a minute latency: gst-launch v4l2src ! video/x-raw-yuv, width=640, height=480 ! queue min-threshold-time=30000000000 max-size-time=0 max-size-bytes=0 max-size-buffers=0 ! xvimagesink