Skip to content

Conversation

mash-graz
Copy link

because gst_clock_set_calibration () will not be called by the present code, gst_clock_unadjust_unlocked () returns unexpected values.

i don't know, if you can accept this very simple fix, but it simply tries to use the same clock source in the overlay module and the parser. this seems to work in my basic gstreamer experiments.

Fixes: #6

@wmanley
Copy link
Contributor

wmanley commented Apr 14, 2020

because gst_clock_set_calibration () will not be called by the present code, gst_clock_unadjust_unlocked () returns unexpected values.

Do you know why this is? We set the GST_ELEMENT_FLAG_REQUIRE_CLOCK flag so in theory set_clock should be called, which calls gst_clock_set_calibration.

i don't know, if you can accept this very simple fix, but it simply tries to use the same clock source in the overlay module and the parser. this seems to work in my basic gstreamer experiments.

When I've used latency-clock the overlay and the parser are running on different machines, so can't share the same clock. Are you running with them in the same GStreamer pipeline?

@KMuthumala
Copy link

I also use to different machines, and clock times are different in two machines. (one is a ubuntu 16.04 installed pc, and another one is ubuntu 20.04 installed KHADAS vim3 sbc), i tried using ntp time server also. But the issue remains same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

clock base differences
3 participants