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 750381 - ksvideosrc: buffers have no timestamp
ksvideosrc: buffers have no timestamp
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Windows
: Normal major
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-04 07:27 UTC by Philippe Renon
Modified: 2015-06-04 12:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Philippe Renon 2015-06-04 07:27:32 UTC 
This pipeline only displays the 1st frame : ksvideosrc ! timeoverlay ! d3dvideosink

Log shows:
0:00:54.704702145  6108   53C69348 WARN                   pango gstbasetextoverlay.c:2533:gst_base_text_overlay_video_ch
ain:<timeoverlay1> buffer without timestamp, discarding

The issue is related to this changeset : http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/sys/winks?id=1991b5bb6f1d575bea60b5c6b8d2050edf39ccfc
A quick looks shows that the implemented logic is apparently the reverse of what was intended.

This pipeline works : ksvideosrc do-timestamp=true ! timeoverlay ! autovideosink

I also tried to fix the issue by reverting the above mentioned changeset.
The pipeline then works as intended but the log shows these warnings:

0:00:23.757778342  5508   53BA9348 INFO              ksvideosrc gstksvideosrc.c:897:gst_ks_video_src_timestamp_buffer:<ksvideosrc0> lost 2 frames, setting discont flag
Comment 1 Tim-Philipp Müller 2015-06-04 12:34:53 UTC 
Fixed the logic:

commit 96d1331679adc032ccfc2719c0c9954b9751b34b
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Thu Jun 4 13:31:56 2015 +0100

    ksvideosrc: fix logic and timestamp non-muxed streams again
    
    https://bugzilla.gnome.org/show_bug.cgi?id=750381

(Not that it's clear to me why mux streams should not be timestamped..)