From aa8f6a2147e0d43a0030d462e6ef9bcd57b89137 Mon Sep 17 00:00:00 2001 From: Stefan Klug Date: Fri, 8 May 2026 11:12:09 +0200 Subject: [PATCH] gst: gstpipewireclock: Add error message to detect time drift Sometime cases were observed, where the time returned from pw_stream_get_time_n() had incorrect values. The root cause was not fully tracked down. Roughly the case was as follows: A gstreamer pipeline with two gstpipewiresrc elements. One audio and one libcamera besed video src, both fed into a mp4 encoding mux. The cock was provided by the audio gstpipewiresrc. Now between starting the pipewire video stream and receiving the first camera frame pw_stream_get_time_n() returned strange values (It seemed like it was using the audio rate for something internally). This wrong value was used to initialze pclock->start_time and therefore all following calls to gst_pipewire_clock_get_internal_time() returned completely wrong values. Add a warning to hopefully catch these cases. I don't have a proper use case to test the clock interpolation done in gst_pipewire_clock_get_internal_time() so I can't drop that (which would remove the bogus call to pw_stream_get_time_n() alltogether), although it feels like the right thing to do. Signed-off-by: Stefan Klug --- src/gst/gstpipewireclock.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/gst/gstpipewireclock.c b/src/gst/gstpipewireclock.c index fc7e72448..f2427d822 100644 --- a/src/gst/gstpipewireclock.c +++ b/src/gst/gstpipewireclock.c @@ -64,6 +64,10 @@ gst_pipewire_clock_get_internal_time (GstClock * clock) result += pclock->time_offset; pclock->last_time = result; + if ( ABS(GST_CLOCK_DIFF(now, result)) > GST_SECOND * 5 ) { + GST_ERROR ("clock: %p Large timedrift detected. Something is wrong.", pclock); + } + GST_DEBUG ("%"PRId64", %d/%d %"PRId64" %"PRId64" %"PRId64, t.ticks, t.rate.num, t.rate.denom, t.now, result, now); #else