Any impact of Chrome Update( 55.0.2883.75)

1

Since Google chrome was updated to 55.0.2883.75, I got googAvailableReceiveBandwidth is always 0.
It seems the BUG of chrome.
Is this BUG can be bad effect to Licode?

2

Well, I’m not getting 0 in googAvailableReceive bandwidth but you might be onto something there…
according to [this] (https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/discuss-webrtc/BqqFMSR6s1E/rlPYFD0NCQAJ)
Chrome >55 is running all the bandwidth estimation logic in the sender side, which will screw some of our REMB based logic. I stupidly left 'transport-cc' enabled in rtp_media_config. I will disable this in the master branch and we will further investigate this.

Thanks for the tip.

3

Thank you for your comment.

Well, I’m not getting 0 in googAvailableReceive bandwidth

I tried Chrome 55 on 3 PCs(Win7, Win10, MacOS). And I got 0 value always.
What is going on to me…

Anyway, I would like to tell you what I did after my first comment.
I did screenshare(sender: HIGH bandwidth, recever: two recievers - one is HIGH bandwidth other is LOW).

  1. sender(Chrome 54) – reciever(Chrome 54)
  2. sender(Chrome 55) – reciever(Chorme 55)

RESULT
1)
googAvailableReceive is not 0.
When LOW bandwidth reciever enters, sender’s googAvailableSend bandwidth is reduce to LOW reciever’s googAvailableReceive bandwidth.
The quality of the video gets worse and LOW reciever can recieve.(this result is what I expected)

googAvailableReceive is 0.
When LOW bandwidth reciever enters, sender’s googAvailableSend bandwidth is not reduce.
The quality of the video does not seem to get worse and recever’s video often stops.

So I think getting 0 value from googAvailableReceive is bad for Licode.

I hope this information will be some help for your investigation.