GNOME Bugzilla – Bug 747722
winks: buffer is too late
Last modified: 2015-04-12 11:00:44 UTC
When displaying video from a camera (ksvideosrc ! queue ! videoconvert ! d3dvideosink), i get warnings like this: WARNING: from element /GstPipeline:pipeline0/GstD3DVideoSink:d3dvideosink0: A lot of buffers are being dropped. Additional debug info: ../../../../gstreamer-0ad06434daae08fea343741de1fa8fc386f52808/libs/gst/base/gstbasesink.c(2793): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstD3DVideoSink:d3dvideosink0: There may be a timestamping problem, or this computer is too slow. With added identity element and extra debug levels i can see this: /GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (614400 bytes, dts: 0:00:00.000000000, pts:0:00:01.255244356, duration: 0:00:00.033333333, offset: 0, offset_end: 1, flags: 00000040 discont ) 02a34988 0:00:01.430347548 3904 29b8308 DEBUG GST_PERFORMANCE gstbufferpool.c:1251:default_release_buffer:<d3dsurfacebufferpool1> discarding buffer 02a34ca8: size 1228800 != 614400 0:00:01.431033364 3904 29b8308 DEBUG GST_PERFORMANCE gstbufferpool.c:1251:default_release_buffer:<d3dsurfacebufferpool1> discarding buffer 02a34d48: size 1228800 != 614400 0:00:01.432655536 3904 29b87b8 DEBUG ksvideosrc gstksvideosrc.c:770:gst_ks_video_src_query:<ksvideosrc0> reporting latency of min 0:00:00.033333333 max 0:00:00.033333333 0:00:01.433146354 3904 29b8308 DEBUG GST_PERFORMANCE gstbasesink.c:2785:gst_base_sink_is_too_late:<d3dvideosink0> buffer is too late 0:00:01.259009705 > 0:00:00.053333333 and later on: /GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (614400 bytes, dts: none, pts:0:00:02.852976978, duration: 0:00:00.033333333, offset: 0, offset_end: 1, flags: 00000000 ) 02d25208 Note that in one case dts is 0, and in all others it's none. dts != none set in the src element causes the warning to be displayed later in the sink. The function that sets dts to 0 from time to time is gst_base_src_do_sync(). This can be fixed by adding explicit GST_BUFFER_DTS (buf) = GST_CLOCK_TIME_NONE; to the end of gst_ks_video_src_timestamp_buffer().
Why is basesrc setting DTS to 0 every now and then?
Maybe it does that only for the first, but then the buffer gets recycled from a pool?
That would explain it, yes. But why does it set timestamps at all if do-timestamp=false?
No idea. I assumed that having a stream with dts == GST_CLOCK_TIME_NONE is somehow bad, which is why it does it. Note that having dts == 0 on the first buffer once, at the very beginning, is OK (does not cause any warnings from the sink, probably because of the state the pipeline is in). I agree about the buffer pool - it looks like winks allocates two spare buffers, and gst_base_src_do_syn() sets dts to 0 on one of them. Later winks will sometimes use this buffer without re-setting dts. DTS setting was committed by http://cgit.freedesktop.org/gstreamer/gstreamer/commit/libs/gst/base/gstbasesrc.c?id=d7fdf75e137f804b5e0215eca95593f4bdc465e7 and changed by http://cgit.freedesktop.org/gstreamer/gstreamer/commit/libs/gst/base/gstbasesrc.c?id=892d36211fac3a2c663d9a1198c8a75a2dc3645e (the latter makes no difference here - stream start is also 0 in my case). Right now i'm inclined to think that the bug is in winks re-using old buffers without re-setting their attributes.
Let's go with that for now then, it still seems wrong the basesrc sets any timestamps for us if we don't want that. commit 91853015b71b20aac9f91b096c1e0ac114988744 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun Apr 12 13:01:56 2015 +0200 winks: Reset DTS to GST_CLOCK_TIME_NONE Otherwise we might get a previous DTS set from a recycled buffer that we get back from a buffer pool, which then confuses synchronization. https://bugzilla.gnome.org/show_bug.cgi?id=747722