mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2026-05-31 21:38:19 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

gst: gstpipewireclock: Add error message to detect time drift

Browse source 
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 <stefan.klug@ideasonboard.com>
This commit is contained in:
Stefan Klug 2026-05-08 11:12:09 +02:00
parent c8f81fcdbb
commit aa8f6a2147
1 changed files with 4 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

4
src/gst/gstpipewireclock.c
View file

@ -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