Issues with Drifting in Synchronized RTSP Streams and tcp-timestamp Flag

General Discussion
1

Hello everyone,

I’m currently facing drifting issues with my synchronized RTSP streams and I’m trying to utilize the tcp-timestamp flag to address this. However, I’ve encountered a problem: the documentation indicates that this feature is available starting from version 1.26, but the latest release I have is 1.24.9.

Here’s the pipeline I’m using:

bash

gst-launch-1.0 \
    rtspsrc location='{CHANNEL_1}' latency=500 drop-on-latency=true tcp-timestamp=true ! rtph265depay ! h265parse ! avdec_h265 ! videoconvert ! m.sink_0 \
    rtspsrc location='{CHANNEL_2}' latency=500 drop-on-latency=true tcp-timestamp=true ! rtph265depay ! h265parse ! avdec_h265 ! videoconvert ! m.sink_1 \
    rtspsrc location='{CHANNEL_3}' latency=500 drop-on-latency=true tcp-timestamp=true ! rtph265depay ! h265parse ! avdec_h265 ! videoconvert ! m.sink_2 \
    videomixer name=m sink_1::xpos=1920 sink_2::xpos=3840 ! x264enc speed-preset=ultrafast tune=zerolatency ! h264parse ! splitmuxsink async-finalize=true location='videos/{HOSTNAME}_full_{timestamp_process}_%05d.mp4' max-size-time={VIDEO_DURATION_SECONDS}000000000

Since I can’t upgrade to version 1.26 yet, does anyone have suggestions on how to mitigate the drifting issue with the current version? Are there alternative approaches or settings I can try to improve synchronization between the streams?

Any help or insights would be greatly appreciated!

Thank you!

2

I’ve requested this to be backported here. Should hopefully be in 1.24.10 then.

Until then you’d have to backport the patch. It should apply cleanly to 1.24.9.