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.
Author: Sebastian Dröge <email@example.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.