New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 668935 link

Starred by 2 users
Status: WontFix
Owner:
sergeyu@chromium.org
Closed: Apr 2017
Cc:
█ philipel@chromium.org
hbos@chromium.org
holmer@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

googAvailableReceiveBandwidth is always 0

Reported by c.facto...@gmail.com, Nov 28 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.59 Safari/537.36

Steps to reproduce the problem:
1. Open following URL https://webrtc.github.io/samples/src/content/peerconnection/pc1/ , then push "START" and "CALL".
2. Open a new tab and browse to chrome://webrtc-internals
3. Expand the "bweforvideo" section

What is the expected behavior?
Receiver side googAvailableReceiveBandwidth shows Nonzero values.
Stabel Version (54.0.2840.99 (64-bit)) shows Nonzero values.

What went wrong?
Receiver side googAvailableReceiveBandwidth is all zero.

Did this work before? Yes Stabel Version (54.0.2840.99 (64-bit))

Does this work in other browsers? N/A

Chrome version: 55.0.2883.59  Channel: beta
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 24.0 r0

I tried other versions(56.0.2924.3 dev and 57.0.2931.0 canary) and got same problem.

Comment 1 by guidou@chromium.org, Nov 28 2016

Owner: hbos@chromium.org

Comment 2 by guidou@chromium.org, Nov 28 2016 

hbos@, can you take a look?

Comment 3 by guidou@chromium.org, Nov 28 2016

Status: Assigned (was: Unconfirmed)

Comment 4 by c.facto...@gmail.com, Dec 2 2016 

I tried 55.0.2883.75 stable version released today and I got Zero value from googAvailableReceiveBandwidth, however googAvailableSendBandwidth provides Nonzero value.
I got same result on Mac, Win7, Win10. 
Is this a bug?

Comment 5 by hbos@chromium.org, Dec 2 2016

Cc: hbos@chromium.org
Labels: -Pri-2 Pri-3
Owner: sergeyu@chromium.org
Sounds like a bug yes. sergeyu is this related to https://bugs.chromium.org/p/webrtc/issues/detail?id=6710, https://bugs.chromium.org/p/webrtc/issues/detail?id=6332 or estimation work you've been doing? (Did a quick git log search)

Comment 7 by c.facto...@gmail.com, Dec 2 2016 

Thank you for your comment.

It seems like fixing in those two references about SEND bandwidth. 
However, this problem is on RECEIVE bandwidth. 
Is this fixing also for Receive problem?

Comment 8 by anatolid@chromium.org, Mar 31 2017 

Can we have an update on this regression?

Comment 9 by c.facto...@gmail.com, Apr 3 2017 

I tried 57.0.2987.133 stable version and I got only zero value from googAvailableReceiveBandwidth.
However, when I edit the SDP by the following procedure, I can get a nonzero value.

1. Open following URL https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/
2. Push “Get media”, “Create peer connection” and “Create offer”
3. Delete the lines containing "transport-cc" from Offer SDP text area
4. Push “Set offer”, “Create Answer” and “Set answer”
5. Open a new tab and browse to chrome://webrtc-internals
6. Expand the "bweforvideo" section

Comment 10 by anatolid@chromium.org, Apr 6 2017 

sergeyu@ are you looking into this?

Comment 11 by sergeyu@chromium.org, Apr 6 2017

Cc: philipel@chromium.org holmer@chromium.org
Status: WontFix (was: Assigned)
googAvailableReceiveBandwidth is set only when using receiver-side BW estimation. When using sender-side BW estimation this value is not set (see https://codesearch.chromium.org/chromium/src/third_party/webrtc/modules/remote_bitrate_estimator/remote_estimator_proxy.cc?type=cs&l=62).
►

Sign in to add a comment