BWE's frozen on the same value periodically about media-server

[murillo128]

Hi @skmax, thank you for the issue report and the PR!

Probing is never sent if RTX history doesn't have appropriate packets.

If you check the code, the size for the probe is calculated based on the period of the last probe was sent. So if the packets on the queue are too big, the size will be accumulated for the next time the probe timer is fired and eventually they will be sent.

I would prefer to avoid sending padding only rtx packets for probing if there are any on the history.

The calculation of probing which needs to be send looks like inconsistent

The outgoing bitrate on the DTLSICETransport is updated when the Probe method is called, while the one on the SendSideBandwidthEstimation is updated when the packet is sent. So the DTLSICETransport one should be a bit lower than the one in the SendSideBandwidthEstimation, but there should not be such a huge difference.

I will double check and see if there is an issue when printing the value.

[skmax]

If you check the code, the size for the probe is calculated based on the period of the last probe was sent. So if the packets on the queue are too big, the size will be accumulated for the next time the probe timer is fired and eventually they will be sent.

Yes, it's been accumulating, but sometimes on small bitrates I can see that it never gets to the point where the instant probeSize is bigger than at least one packet in the history if we're just increasing the target bitrate for 5% on each estimation tick.
Also, I think that it might be not a good idea to send really huge packet right away. The router might drop it because the real bandwidth limitation thus we won't be able to estimate the bandwidth correctly. I suppose it's better to send the probing uniformly during the second instead of occasuanly send a relativly huge amount of data.

The outgoing bitrate on the DTLSICETransport is updated when the Probe method is called, while the one on the SendSideBandwidthEstimation is updated when the packet is sent. So the DTLSICETransport one should be a bit lower than the one in the SendSideBandwidthEstimation, but there should not be such a huge difference.

I will double check and see if there is an issue when printing the value.

Ok, please, let me know what you found regarding the issue. But I doubt it's a pringting problem. The probing started to work more accuratly after using the same accumulator in DTLSICETransport (see PR, please)
Are there any particular reasons to use both accumulalators instead of a single one? As far as I can see it's used only for bandwidth estimation. For me it looks like it makes two points of truth instead of one and the code should take care that both of them are in sync.

[skmax]

@murillo128 What are your thoughts on this?

Please, let me know if you need more information or logs

[murillo128]

I am bit hesitant to commit a change in the BWE code without a reliable way of reproducing the issue. Would it be possible to check if the issue is still reproducible with the latest media server?

[skmax]

Hi @murillo128
BWE doesn't work for me at all in the latest version of media server. Here is the setup: https://github.com/skmax/media-server-demo-node/tree/bwe-debug-demo-latest

Also, here is a demo page with the issue that I described above (it uses v0.113.2): https://github.com/skmax/media-server-demo-node/tree/bwe-debug-demo
BWE freeze from both cases are relatively quickly reproducible for me there, especially in the static or low-quality video when the receiving bitrate's quite low

[murillo128]

could you describe the steps to reproduce the issue an what is the actual vs expected result?

I ran the bwe-debug-demo-latest and it is working fine. One last thing, are you running it on linux or mac?

[murillo128]

I think I have found the issue, please test with the latest version on the github project