clock base differences

[mash-graz]

the clock base in the overlay and parser module differ, because gst_clock_set_calibration doesn't get called before gst_clock_unadjust_unlocked in

latency-clock/gsttimestampoverlay.c

Line 227 in c2d1661

render_realtime = gst_clock_unadjust_unlocked (

.

[wmanley]

the clock base in the overlay and parser module differ, because gst_clock_set_calibration doesn't get called before gst_clock_unadjust_unlocked in

Do you know why this is? I would have expected gst_timestampoverlay_set_clock to be called before transform_frame_ip.

[tianyi-lu-ocean]

@wmanley, I am trying to run the experiment on the same machine, however, the latency in the log is crazy, it also has non-zero hours and minutes values. I don't understand why it looks like this,

0:01:37.876425346  5528   0x7f4400c760 INFO        timeoverlayparse gsttimeoverlayparse.c:201:gst_timeoverlayparse_transform_frame_ip:<timeoverlayparse0> Latency: 4641988:22:17.686006092

My guess would be this call gst_clock_unadjust_unlocked () in gsttimestampoverlay.c, per GStreamer doc, it says,

Converts the given external clock time to the internal time of clock, using the rate and reference time set with gst_clock_set_calibration. This function should be called with the clock's OBJECT_LOCK held and is mainly used by clock subclasses.

However, in gsttimeoverlayparse.c, it is trying to use the external time to subtract the converted internal time, in our case, it is the render_realtime

latency-clock/gsttimeoverlayparse.c

Line 199 in c2d1661

latency = clock_time - timestamps.render_realtime;

That is just my guess, please correct me if I am wrong, thanks.