This message was deleted.
# helpdesk
s
This message was deleted.
a
Hmm. The switch happens, even without refresh, but it takes unexpectedly long (about a minute). I have seen that faster with the
demo
Update: Not a minute, about 30 to 40 secs, but that is OK, if it can be explained like so. If the resolution drops it takes less than 5 secs. The way up again takes longer (about 30-40 secs) Does that make sense?
f
That is correct. Faster reaction to drop quality to prevent further congestion. More conservative ramp back up to ensure it does not oscillate too much.
a
That makes absolutely sense and sounds very logical. Thanks
As additional question: Is the REMB related trace something to be concerned about?
2023-11-27T10:26:58.314Z	DEBUG	livekit.pub.sfu	buffer/buffer.go:237	REMB not supported, RTCP feedback will not be generated	{"room": "abcde", "roomID": "RM_mjSNt3p5WRiM", "participant": "GO", "pID": "PA_WLYj9NNsGQ2B", "remote": false, "trackID": "TR_VCVDfX9oxq4VXd", "relayed": false, "mime": "video/h264", "layer": 0}
f
No, it is not used in upstream.
a
Perfect. Thanks
Sorry, again me with a "last" question regarding this: In my Web client I have added a method to track
ConnectionQualityChanged
When a drop happens (e.g. from LTE to 3G), the video stream is about 5 seconds later 320x180. The connection quality message for the drop arrives additional 5 seconds later and reports "good" (while the image is already at "poor") just to go to "poor" after additional 5 seconds. I'm also observing this 5 secs delay between visual increase/decrease of quality and the SDK message. Is there a reason for this?
Here is a little video demonstrating the "issue". Check for "Connection quality..." on the left

https://www.youtube.com/watch?v=bA65DYGsiwU▾

f
Yeah, that is expected. There is room for improvement there. But, in general ConnectionQuality is not designed to reflect state immediately. It runs every 5 seconds (hence the 5 second latency you see) so that the participant updates are not too much as room size increases. And the video quality also does not drop linearly with bit rate. Here is a study - https://webrtcbydralex.com/index.php/2018/10/11/webrtc-video-quality-assessment/. So, the quality does not drop to
POOR
immediately. It is time weighted (exponential decay). So, it takes longer at lower bit rate to report lower quality. All this is not perfect. ConnectionQuality is more of an indicator of problem and is not meant to be exact at all times.
a
Sure. Thanks for confirmation. I don't have a problem with that, it just came to my attention. I'm used to get a "layersChange" indication from MediaSoup as soon as it happens.
f
Got it. If you need layer change notification, can you please file a issue at https://github.com/livekit/livekit and we will have a look. If you could point to MediaSoup documentation on that, it will be great.
a
Here you are https://mediasoup.org/documentation/v3/mediasoup/api/ Check for consumer.on(“layerschange”, fn(layers)) Regarding the issue: No, no stress at all. I don't need it, I was just using it for information 🙂
🙇🏽 1
👍 1