What are the simulcast changes should I do while updating Daily from 0.47 to latest version

svm_agilis · February 5

Hi

We have been using Daily version 0.47 with camSimulcastEncodings method for configuring simulcast layers and setBandwidth method to control what all layers to upload based on network changes. But configuring simlcast layers have been changed in the latest version.

I have following questions regarding how to configure simulcast layers and control these layers when network and CPU load changes:
1. Should I continue to use setBandwidth method when network changes ? Or should I use updatesendSettings method.
2. How to update send settings in the following cases:
a. When high network and high cpu load
b. when low network and low cpu load
c. when low network and high cpu load

mark_at_daily · February 6

Hi @svm_agilis!

You're right. We've deprecated camSimulcastEncodings in favor of sendSettings: https://docs.daily.co/reference/daily-js/daily-call-client/properties#sendSettings . sendSettings includes a type definition, which makes it easier and safer to use. It also uses the same object provided to the updateSendSettings() method, which you can use to dynamically change send settings in a call.

Answers to your questions:

We recommend using updateSendSettings().
This really depends on your application's needs. We've added a presets that you can use: https://docs.daily.co/reference/daily-js/instance-methods/update-send-settings#main . But, your application might need different settings.

Generically, here's what I would advise:

Good network, but high CPU: It really depends on the reason why the CPU is high, which you can gather from the cpu-load-change event. If the reason is encoding, you either want to try a lower preset, or drop the top layer. You can drop the top layer using the maxQuality property in updateSendSettings.
Bad network and low CPU: Depends on the application and how bad the network is, but first trying the bandwidth-optimized preset to see if network conditions are improved. If not, you can subsequently drop the top layer by setting maxQuality: medium.
Bad network and high CPU: It probably makes sense to drop the lop layer and set maxQuality: medium.

Hope this helps. If you have any other questions, don't hesitate to reach out.

svm_agilis · February 16

Thank you so much 🙂 @mark_at_daily

I have another question. In Daily we have 3 thresholds for networks, namely good, low and very low.

I use 3 layers with bitrates of 120, 400 and 1660 kbps.

I would like to use updateSendSettings to control which layers a participant should publish in the following way:

I would like to send 3 layers by setting maxQuality as high when network threshold is good.
Send 2 layers by setting maxQuality as medium when network threshold is low.
Send 1 layer or turn off local camera by setting maxQuality as low when network threshold is very low.

Please correct me if this is not a proper way to do or suggest if you have any alternatives.

But I am facing an issue in following the above approach . Because I get network threshould as good even when the max uplink bandwidth is 300 kbps which I set using network link conditioner. So with this threshold as good and quality as 10 at 300kbps uplink. the maxQuality will be set as high and 300 kbps is not sufficient for sending 3 layers. Sometimes I do get threshold as low and quality as 9 at 300kbps uplink.

Or should I also consider any other parameters from network stats such as quality or avaipableOutgoingBitrate from network stats?

mark_at_daily · February 16

@svm_agilis, what you proposed makes sense. Some clarification:

The network-quality-change event is driven by packet loss.
There are other factors at play that will automatically modify what layers are sent and received when bandwidth is constrained. Specifically, on the send side, the browser will attempt to automatically lower the resolution when there is a bitrate drop but no packet loss. On the receive side, the SFU will drop either the frame rate or a layer when the download bitrate isn't enough to support the requested layer.

To see what affects the Network Link Conditioner is having, you can check out Chrome's webrtc-internals: chrome://webrtc-internals and inspect the outbound-rtp video for the sender and inbound-rtp video for the receiver. This will help you get a better grasp on what's happening.

It's worth mentioning that we're working on improvements that handle these situations automatically, so that most developers don't have to deal with the complexity of these situations. We've started an early access program for this feature for customers who predominantly have 1:1 calls. Our goal is to roll out support for multi-party calls by the end of Q1. If you app has 1:1 calling, then we can share details now. If your app has mostly multi-party calls, then we can share details in March.

svm_agilis · February 16

Hi @mark_at_daily
Thank you so much 🙂.

Below I explained the exact issue what I am facing. Can you please have a look?
I am really sorry for the long story 😅😔.

I use 3 encodings
encodings: {
low: {
maxBitrate: 120 * 1000,
scaleResolutionDownBy: 4,
maxFramerate: 15,
},
medium: {
maxBitrate: 400 * 1000,
scaleResolutionDownBy: 2,
maxFramerate: 24,
},
high: {
maxBitrate: 1660 * 1000,
scaleResolutionDownBy: 1,
maxFramerate: 24,
}
}

I would like to use updateSendSettings to control which layers does a participant should publish.

I would like a participant to publish
1. all the 3 layers by setting maxQuality as high, when the network threshold is good and when there is enough bandwidth available for publishing videos such as 2180 kbps (1660 for 2nd layer +400 for 1st layer+120 for 0th layer)
2. only low and medium layers by setting maxQuality as medium, when the network threshold is low and when there is enough bandwidth available for publishing videos such as 520 kbps (400 for 1st layer+120 for 0th layer)
3. only last layer by setting maxQuality as low, when the network threshold is very-low and and when there is enough bandwidth available for publishing videos such as 120 kbps for 0th layer
mute local camera if there is no bandwidth available for sending atleast the low layer of 120 kbps.

I used networkLinkConditioner for simulating different networks.
I am testing with only one participant. I run call by setting topology as SFU. And I set uplink as 300kbps in networkLinkConditioner in order to check how my application behaves at low networks. I didn’t give any limit for downlink.

I considered only network threshold parameter for checking network quality.

I thought I can set maxQuality as high so that I can send all the 3 layers(2nd layer with 1660kbps, 1st layer with 400kbps and 0th layer with 120kbps) ,when the network threshold is good. But I am wrong, because I am getting network threshold as good even when I set uplink bandwidth as 300kbps using networkLinkConditioner (which is not sufficient for sending all the 3 layers). And also from the stats I can see another parameter availableOutgoingBitrate as 308000 which is near to the uplinkBandwidth I set using networkLinkConditioner.

same way I though to set maxQuality as medium and low when the network thresholds were low and very-low. I am wrong here as well.

1. At availableOutgoingBitrate = 300kbps, I am getting network thresholds as high when quality ranges from 11 to 100,
2. At availableOutgoingBitrate = 300kbps, I am getting network thresholds as low when quality is 8 to 10.
3. At availableOutgoingBitrate = 300kbps, I am getting network thresholds as very-low when quality is <= 7. these values changes sometimes.

Daily's default video encodings:
encodings: {
low: {
maxBitrate: 90 * 1000,
scaleResolutionDownBy: 4,
maxFramerate: 15,
},
medium: {
maxBitrate: 200 * 1000,
scaleResolutionDownBy: 2,
maxFramerate: 15,
},
high: {
maxBitrate: 680 * 1000,
scaleResolutionDownBy: 1,
maxFramerate: 30,
}
}

after I see these above Daily’s default-video encodings, I though I would get
1. network threshold as good when uplink bandwidth or availableOutgoingBitrate as around 600-800kbps.
2. network threshold as low when uplink bandwidth or availableOutgoingBitrate as around 300-500kbps.
3. network threshold as very-low when uplink bandwidth or availableOutgoingBitrate as around 100-300kbps.
But I am wrong here as well.

Am I following the correct way of update send settings? If so, should I continue by following only the network threshold parameter for update send settings or should I also follow quality and availableOutgoingBitrate parameters or any other parameters from network stats? Or Should I test with 3-4 participants in a call?

If I am wrong please suggest proper way of update send settings?
Thank you again 🙂🙏

mark_at_daily · February 16

The short answer is that to do this in a way that handles various real-world network conditions, the solution is very complicated. Over the course of last year, we built up all of the methods, events, and data to support an algorithm like you're proposing. This is doable in your app, but it's complex. We'll likely write about the technical details in a future blog series.

In discovering how complex the solution is, we decided to instead roll this out as a feature you can enable automatically. We're calling this feature Daily Adaptive Bitrate. The feature ensures that your call is always stable, regardless of network conditions. And when there is sufficient network throughput, the video quality increases. We have this feature in early access right now for 1:1 calls. We'll deploy this in Q1 for multi-party calls. Given what we've learned in building this feature, I would strongly suggest that you wait to enable the feature we're deploying. You can read more about it here: https://dailyco.notion.site/dailyco/Daily-Adaptive-Bitrate-Early-Access-3d8950c6078e4dc6a33c57f96b8fc1dc

svm_agilis · February 16

Thank you @mark_at_daily .
I will be waiting for this feature.

But my overall doubt is, is that a proper way to send high layers when the threshold is good when the uplink is at 300kbps which is not even sufficient for sending the 0th layer of 120kbps.
This is what I used to follow in Daily 0.47 version .

I think I got this code from Daily's examples demo

mark_at_daily · February 16

Instead of using setBandwidth, you should use updateSendSettings() to set the maxQuality to 'high', 'medium', or 'low' depending on the network-quality-change level of 'good', 'low', or 'very-low', respectively.

svm_agilis · February 16

Yeah I understood that.

But does it make sense to set maxQuality as high when the uplink bandwidth is set to 300kbps or availableOutgoingBitrate is 308000 from natwork stats, even though the network threshold is good and network qualitu as 100.

I think at 300kbps uplink or when availableOutgoingBitrate= 300000, I should set maxQuality as medium or low. And the threshold value would have been low or very-low rather than as high. I thought this way because even the daily's medium layer encoding is 200kbps.

Thanks for your patience 🙂

mark_at_daily · February 16

But does it make sense to set maxQuality as high when the uplink bandwidth is set to 300kbps or availableOutgoingBitrate is 308000 from natwork stats, even though the network threshold is good and network qualitu as 100.

In this scenario, sending 1.6 Mbps does not make sense. It's worth noting that when there's congestion, the availableOutingBitrate value becomes very noisy. Because of the way the congestion control algorithms work, availableOutgoingBitrate may exhibit a sawtooth pattern due to things like network probes. You will not want to use only that value. This is where the complexity comes in.

Other things to consider:

how to make decisions on what to send since availableOutgoingBitrate by itself is too noisy
how do you make sure that the receiving clients have enough download bitrate to receive what the sender is sending. Ex: if user A can send 1.6Mbps, but user B cannot receive 1.6Mbps, then it would be ill-advised to send that amount of video

We've figured out answers to this for the 1:1 case and are working on a solution for multi-party calls.

svm_agilis · February 19

Instead of using setBandwidth, you should use updateSendSettings() to set the maxQuality to 'high', 'medium', or 'low' depending on the network-quality-change level of 'good', 'low', or 'very-low', respectively.

I did set maxQuality as 'high' and 'medium' , when the threshold is 'good' and 'low' respectively.
Should I set maxQuality as 'low' or should I turn off local camera, when the threshold is 'very-low'?
I heard that "we should lower the quality when the bandwidth is low and we should turn off local camera when there is no enough network.

What are the simulcast changes should I do while updating Daily from 0.47 to latest version

Answers

Categories