This message was deleted.
# cloud
s
This message was deleted.
d
thinking about this.. we currently don't expose this in a meaningful way.. end to end latency is essentially three legs: • publisher -> SFU • SFU <-> SFU (routing within our mesh) • SFU -> subscriber you can currently get publisher -> SFU stats from a publisher's webrtc stats and similarly for the subscriber we currently don't expose any info for the time spent within the Mesh..
❤️ 1
CC: @acoustic-engineer-41666
would be great to expose within the dashboard.. perhaps under published and subscribed tracks (avg end to end latency)
❤️ 1
a
@important-telephone-80974 what’s your goal here? Is this for internal metrics or do you want to share this with your users?
i
Thanks - this is just for me. I will likely have a bunch of different rooms / different publishers and I want to see at one glance outliers etc
👍 1
So I would have this within my internal dashboards (grafana dashboards or others) and alert in case of big outliers
So ideally ability to grab metrics and publish them in a Prometheus compatible format or other would be a big plus
👍 1
But just in the livekit dashboard is great already 👍
Another aspect that I had actually forgotten about: • I need to sync some metadata with the video / audio. So if the delay of the media is 1s, I need to delay the metadata by 1s as well etc. This is actually more important for me - and that cannot be really solved with metrics in the dashboard
d
that makes sense.. though that problem goes away if the latency is never 1s right? generally speaking, something is seriously wrong if latency is pushing that high.. when things are operational, we expect latency to be between 80ms-500ms end to end.
i
yeah I don’t need to synchronise as much if the delay is < 200-300ms, 500ms is the limit for my use case. Basically the user can press a bunch of buttons on the website which impacts the live stream, so they get a straight feel of the latency by how fast the stream responds
at 1s - 1.5s, it feels a bit painful. Right now, I don’t really have any insights on that which is an issue for my use case
d
for sure! this is the problem with cherry crush on TikTok 🤣
I think part of the reason why this is the case is due to ingest delays you are seeing. if we can optimize that path, ideally you don't have to worry about synchronizating metadata
❤️ 1
i
yeah that makes sense
otherwise, I am not familiar with cherry crush on tiktok 😛 will look up what that it is!
d
lol, it's a silly TikTok account that pretends to be an NPC while viewers gifts her food items.. it's gotten viral lately you can tell the 5s+ latency resulting from them using HLS
i
ah ok 🙂 I think I remember seeing it on Twitter / X now that you mention what it is... I just didn’t know that name