[Bug 793683] gstclockoverlay: Add ability to specify which time to be displayed by GstClockOverlay

[GStreamer (GNOME Bugzilla)]

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

--- Comment #7 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Abhinav from comment #6)
> Hi Nicolas, 
> 
> Thanks for quick comment and guidance. 
> 
> > It's what I just said before, the users decides the when by placing the
> > clockoverlay at specific place in it's pipeline. If you have a live capture,
> > and want something close to the capture time, place it right next to your
> > capture source.
> > 
> > > IMHO, most users would be interested in Wall Clock which corresponds to
> > > buffer.
> > 
> > I'm not sure what you want exactly. 
> 
> Sorry for not being able to clearly articulate our requirement earlier. 
> What we want is to display "wall clock" at the time of video capture (with
> sub second precision), in the format as already supported by clokoverlay.

Maybe you should have used capture-time then to describe your mode. There is an
issue though, there is no sub-second precision in strftime(). I still think
timeoverlay would be a better place for this.

> 
> Even if we place clockoverlay just next to video capture source (e.g.
> v4l2src) in our pipeline, we observed gap of few seconds as compared to wall
> clock time of recorded video. There can be several reasons (e.g. buffer
> cached at source and so on..), So placing clockoverlay just next to capture
> source is not enough to achieve desired precision. 

Obviously clockoverlay is not going to match the HW capture timestamp. Though,
few seconds tell me that you omitted to properly describe what you are trying
to test. I believe if you could enable time codes for you stream, implementing
timecode support and overlaying both running time and time code using
timeoverlay could do a much better job.

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