This message was deleted.

Hey @adventurous-zoo-7753, this is most likely due to how GStreamer publishing the stream. Once the packets reach LiveKit, there is no buffering on our side (the packet spends <1ms within LiveKit SFU before getting forwarded on). The reason why it's delayed is either • GStreamer isn't able to keep up with real-time publishing. so it adds a bit of skew overtime. (you can take a look at queues/etc that are in your pipeline) • There's something wrong with the PTS that your pipeline is generating, that's falling behind just slightly.

Thanks for the response! Do you know why just restarting LiveKit resolves the issue, if it is a GStreamer problem? I would think that if it were a GStreamer issue, restarting LiveKit wouldn't do anything, and restarting the gst pipeline would

When you restart LiveKit, the track would have to be republished again, effectively "resetting" what the browser thinks is realtime. How do you handle the server going away on the client side? I imagine you are publishing with Go SDK?

sorry, I should have clarified that we're rejoining the room, not restarting the entire server, but yeah we're on the Go SDK 1.4.2 does the track republish then as well? I would guess so but just want to double check

rejoining the room as the publisher? or rejoining the room as viewers?

as the publisher

ok, that's a bit difficult to know.. does it correct itself if the viewer joins?

we haven't actually tested that, I can try that tomorrow and get back to you

if resetting the viewer gets you to live. then it means it's a timestamp/fps issue. with the Go SDK, FPS would have to match the input exactly.

checked this morning, and the latency is still present when a new viewer joins the room

ok, that means the issue is on the publisher side.

that makes sense, thanks!