This message was deleted.
# helpdesk
s
This message was deleted.
e
Here are the logs in the broadcast:
f
In the first log, it is due to packet loss
Copy code
pe: 559, pl: 81,
that is 81 packets lost out of expected 559, that is ~15% loss. That is high loss. The second one is due to high jitter. Which version of server are you on? Please update to the latest. We have removed jitter as we found it to be too volatile and gives false alarm a bunch. Similarly for RTT also. But, high jitter values do indicate a network issue. Looks like there are periods of significant loss too. So, overall not a very stable network which could explain the observed quality.
e
Latest version v1.4.3. My helm config: image: tag: v1.4.3
f
oh my bad, the second log also has significant loss
Copy code
pe: 305, pl: 109
That is almost 33% loss. So, loss is the reason for the quality drops.
e
The quality is not bad, but there is packet loss, right?
f
Yeah, that looks like good chunks of packet loss. Losses need to be repaired, either through NACK from receiver indicating which packets were lost and retransmission by sender OR receiver asking for a key frame as it cannot decode the packets it has (broken sequence due to losses). In either case, it is a disruption (in this case, looks like it has to get key frames, guessing).
e
Is the problem the publisher's internet? Why is there packet loss?
f
Yeah it is on upstream from publisher to the server. So it could be their Internet
e
The same publisher is using multiple platforms and these platforms are using agora rtc and tencent rtc. There is no freezing on other platforms, so it makes sense that packet loss happens when using livekit.
We have also tested 3 different applications using livekit, tencent and agora service, only Livekit has packet loss.
f
Tough to say why that could be without the full deployment picture. Maybe the connectivity from the publisher’s location to where you have deployed LK is not great?
e
There is a 50ms ping from the publisher's location to the server. My server's speed test: https://www.speedtest.net/result/c/ee241cbb-9d79-4260-a382-7b86518ddca6 publisher's speed test:
d
@enough-boots-69343 we really can't say as you are self hosting. hosting providers differ drastically in terms of udp delivery even tho they could maintain a low ping. We have seen this happen with discount hosting providers. if you are comparing to other cloud vendors, it would be better to compare LK Cloud.
related. these speeds look rather low for a server. we typically see 1Gbps+ on a server.
e
png is user's internet speed not server.
e
@enough-boots-69343 do you see the same issues when using LiveKit Cloud? You might want to switch for testing purposes. We have a free plan with 50GB of bandwidth included - no credit card required. Switching should be as easy as changing the server url, api key and secret. If the problem persists, we have more debugging and analysis options to help you quickly.
e
yes, we will test it with Livekit Cloud, I will report the result.
👍 1
@eager-zoo-16408 @dry-elephant-14928 @fancy-wire-61616 We tested. Video freezes are also available in Livekit Cloud. What information is required for your debugging?
d
@enough-boots-69343 can you send us a link to a session that exhibited issues for you?
e
f
There is significant packet loss from the publisher side - https://cloud.livekit.io/projects/p_47iqx46bhs7/sessions/RM_HLgVuZthVxb5/participants/PA_fG3SMFQxekTL. Looks like the path from publisher -> data centre in Frankfurt is experiencing lots of loss.
âž• 1
d
Currently we do not have a data center in your region. However, we are considering bringing up a new region in Tel Aviv.. that should improve the experience significantly for you then.
I'm curious, where are you hosting right now? when you ran the test against self-hosted.
e
@dry-elephant-14928 Our servers are hosted in Falkenstein/Germany.
Publisher's internet speed is very good, ping 50 ms. Except for this person, this problem is not observed in 20 different broadcasters in approximate locations.
d
right, I trust that the speed test is looking decent. However, this is a bit more complicated than that. Speed test is pointing the user to the closest edge server (often hosted by the same ISP). The goal of a speed test is to measure their connection from the ISP to their computer. When you are hosting a server, you'd have to look at how the traffic flows from your server to the user's ISP. And this is really a complicated web of inter-connectivity and peering agreements that most of us don't tend to think about. Based on the session you had shared earlier, it doesn't look like the connection from Germany to the user in Turkey was very good.
e
Could packet losses be caused by the Flutter library? Is packet loss possible due to the code structure that some phone models do not support? Let's not forget that the user has the same packet loss rate with both wifi and cellular data. Does this make any sense to us?
d
it's unlikely. all of our native SDKs run libwebrtc, the same code as Chrome when it comes to communications.
e
We would like to try the livekit cloud again with the servers you will set up in Tel Aviv and look at the packet loss problem.