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 625520 - dc1394src: timestamping problem
dc1394src: timestamping problem
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-07-28 19:39 UTC by Tristan Matthews
Modified: 2011-05-26 07:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
implementes latency query for the dc1394src element (2.83 KB, patch)
2010-08-19 21:32 UTC, Tristan Matthews
needs-work Details | Review

Description Tristan Matthews 2010-07-28 19:39:46 UTC
To reproduce (more likely to manifest itself with multiple cameras at once):

Start a few pipelines as follows:
GST_DEBUG=2 gst-launch -v dc1394src camera-number=0 ! video/x-raw-grayscale, framerate=15/1 ! ffmpegcolorspace ! xvimagesink

GST_DEBUG=2 gst-launch -v dc1394src camera-number=1 ! video/x-raw-grayscale, framerate=15/1 ! ffmpegcolorspace ! xvimagesink

The video will get very choppy and you'll start to see a lot of these warnings:

WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2597): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
There may be a timestamping problem, or this computer is too slow.

Note that if xvimagesink has its sync property set to false, this bug will not show up. Nevertheless it seems like it's a legitimate timestamping problem.
Comment 1 Tim-Philipp Müller 2010-08-06 10:34:07 UTC
dc1394src should probably implement the latency query.
Comment 2 Tristan Matthews 2010-08-17 16:12:19 UTC
In which case, I think the latency value would correspond to the buffer-size (the number of frames in the dma ringbuffer) / framerate, correct?
Comment 3 Tristan Matthews 2010-08-19 21:32:38 UTC
Created attachment 168331 [details] [review]
implementes latency query for the dc1394src element
Comment 4 Sebastian Dröge (slomo) 2011-05-26 07:24:16 UTC
commit 0bb2a4d229f6ec9964ec9b7949b10dca6fa2f752
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Thu May 26 09:22:31 2011 +0200

    dc1394src: Implement LATENCY query
    
    Based on the LATENCY query code in v4l2src and the patch
    by Tristan Matthews. Fixes bug #625520.
Comment 5 Sebastian Dröge (slomo) 2011-05-26 07:25:46 UTC
Comment on attachment 168331 [details] [review]
implementes latency query for the dc1394src element

You have to implement GstBaseSrc::query instead of overriding the query function of the pad. basesrc already handles most of the queries, like POSITION.

Also you should not ask the peer. The LATENCY query is an upstream query and the source gives the first, absolute values. The min latency is the time to capture a single frame, the max latency the time needed to capture the complete buffer