[Bug 784295] timecodestamper: LTC from audio

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Aug 8 07:57:33 UTC 2017


https://bugzilla.gnome.org/show_bug.cgi?id=784295

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #357112|none                        |reviewed
             status|                            |

--- Comment #12 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Review of attachment 357112:
 --> (https://bugzilla.gnome.org/review?bug=784295&attachment=357112)

Generally this seems like a bug in one of the elements, or the code in
timecodestamper.

Setting an offset like this should only be needed if there is an actual
hardware capture bug (where things are delayed more than signalled, e.g. in
your case in ALSA). It's also suspicious that it's *exactly* one frame (is
it?). The alsasrc is not capturing buffers of the duration of one video frame.

::: gst/timecode/gsttimecodestamper.c
@@ +213,3 @@
+          "Add this number of frames to LTC timecode, "
+          "useful if there is an offset between your LTC source and video.",
+          G_MININT, G_MAXINT, 0, G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));

Should it be in frames or nanoseconds? Usually we call this property
"ts-offset" and it's in gint64/nanoseconds.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list