@forever.arihant-- Could you please let us know how to check the remb value in hangout call , that would help us in traiging the issue better.

Thanks!

I don't think hangout uses remb anymore. Hangout is already using transport-cc. This is not a hangout call anyway. Let me know if you need any other info.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@forever.arihant could you please let us know which site/application you are using for making the call and also let us known how to check the REMB value in chrome.

Thank You...

This is Skype webapp using webrtc stack. Also, Chrome doesn't log the remb values that it sends out. We see the drop in incoming remb from the peer's log. Is there a way I can make chrome to log the remb values send out? 
I am currently using the following cml line params to start chrome:
--enable-logging --vmodule=*/webrtc/*=10

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Can anyone from WebRTC team will look into this issue and update thread.

Thank You...

sprang@ can you help with triage?

"the jitter seems to be increased at around the same time" to my ear sounds like the kind of thing the bandwidth estimator might be triggered by to lower the bwe.
Did it not recover after this event or was it stuck at low bandwidth?

Note sure about logging of remb explicitly, but you can get some additional information at runtime from chrome://webrtc-internals if that helps.

holmer@, can you check if this needs further investigation?

forever.arihant, we need more details. From the chrome log you attached it looks like also the other end is sending low REMBs:

[15588:5248:0310/153507.002:VERBOSE1:rtcp_receiver.cc(980)] Incoming REMB: 2862
[15588:9800:0310/153508.477:INFO:bitrate_allocator.cc(79)] Current BWE 10000

so based on this I think you'll have to do some investigations on your end to see why both react to this.

You could record RtcEventLogs which might help us see what's going on:
https://tokbox.com/blog/how-to-get-a-webrtc-diagnostic-recording-from-chrome-49/

Thank everyone for looking into this. I did one more repro with RtcEventslogs enabled and have attached it here.
In this repro its receive only video channel so there is no incoming remb for chrome. The drop in outgoing remb is from around ~2.15M to ~50K.

@holmer: Can you please check the events logs and see whats going wrong? Also is there a way i can decode the event logs locally?

@sprang: It does recover. But the drop from ~2.15M to ~50K has a very bad impact on quality of video. Also ramp-up to ~2M again will take some time.
Is there a way we can make chrome quickly rampup its estimation?

Peer's logs for receiving remb arnd the drop time:
[03/31/2017-14:36:51.163],REMB received bitrate (bps) : 2158780
[03/31/2017-14:36:51.473],REMB received bitrate (bps) : 2158780
[03/31/2017-14:36:51.783],REMB received bitrate (bps) : 2158780
[03/31/2017-14:36:51.783],REMB received bitrate (bps) : 49756
[03/31/2017-14:36:52.143],REMB received bitrate (bps) : 49756

Deleted: event_log.41.2 2.4 MB

event_log.41.2 2.4 MB Download

Deleted: chrome_debug.log 1.4 MB

chrome_debug.log 1.4 MB View Download

You can get graphs from the event log by downloading the webrtc code and building event_log_analyzer:

out/Default/event_log_visualizer event_log.41.2 | python

We are currently prioritizing work on the send-side bandwidth estimator, so I'd recommend taking a look at that. It already has improvements over the receive-side BWE using REMB.

Thanks for the response and sorry for the delay.
I don't see any event_log_visualizer in the out/Default directory that I have. Is this tool supported on windows?