After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747722 - winks: buffer is too late
winks: buffer is too late
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Windows
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-04-12 00:13 UTC by LRN
Modified: 2015-04-12 11:00 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description LRN 2015-04-12 00:13:34 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().
Comment 1 Sebastian Dröge (slomo) 2015-04-12 08:56:31 UTC
Why is basesrc setting DTS to 0 every now and then?
Comment 2 Tim-Philipp Müller 2015-04-12 09:34:41 UTC
Maybe it does that only for the first, but then the buffer gets recycled from a pool?
Comment 3 Sebastian Dröge (slomo) 2015-04-12 10:20:06 UTC
That would explain it, yes. But why does it set timestamps at all if do-timestamp=false?
Comment 4 LRN 2015-04-12 10:43:12 UTC
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 and changed by (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.
Comment 5 Sebastian Dröge (slomo) 2015-04-12 11:00:44 UTC
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 <>
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.