Sorry, when I wrote 1 kbps, I meant 1 mbps.

Any way I can help? Also, 1/ should be "Set x-google-min-bitrate and x-google-max-bitrate..."

Changing component to Video for better triage. A couple questions though:

- Does this only happen if the min *and* max are set?
- Does this only happen for low values like 1kbps?

Hi deadbeef,

Thanks so much for looking into this.

- No, it also happens when only the x-google-min-bitrate is set.
- No. Just to clarify, I meant 1mbps in my initial post, not 1kbps. I just tried it with x-google-min-bitrate set to 1.6mbps, and here's what the bweforvideo looks like (attached). Notice it's transmitting around half of what is available.

Deleted: bweforvideo.png 127 KB

	bweforvideo.png 127 KB View Download

+holmer

It looks like this issue started after 56.0.2924.76 (last known working version). Could this be a regression? Thanks!

It may be related to one of these issues:

https://bugs.chromium.org/p/webrtc/issues/detail?id=7509
https://bugs.chromium.org/p/webrtc/issues/detail?id=7717

But those would cause the bandwidth to drop to the configured "minimum" value... Not 60% of the target.

Hi deadbeef,

It looks like both of the above issues have been patched. How should I go about testing them? As far as I can tell, the latest Chromium master build pulls in the WebRTC repo behind these patches.

Thanks

Here's instructions to reproduce.

1/ Go to https://dl.dropboxusercontent.com/u/758553/WebRTC/html/publish/index.html. 
2/ Press the Publish button. You are now publishing to our test Wowza instance. (Wowza is a media server with support for WebRTC.)
3/ Check bweforvideo graph in chrome://webrtc-internals.

In my tests using 58.0.3029.110, the bweforvideo graph shows a googAvailableSendBandwidth of 2.0 M and a googTransmitBitrate and googActualEncBitrate of just less than 1 M.

As mentioned, this issue does not occur in 56.0.2924.76.

Thanks

I was able to reproduce the issue on 59.0.3071.86. As far as I can tell, the patches for 7509 and 7717 made it into 59.0.3071.86 -- unfortunately, it seems those issues were unrelated to this issue.

Hi deadbeef - Have you had a chance to try my reproduction steps above? Thanks again for the help.

I can reproduce this in Canary. I'll let the video team triage this and investigate further. holmer@, when you have time maybe you could take a look?

Thanks so much. @homer, let me know if I can help.

Hi all, has this been triaged yet?

I wasn't able to reproduce with the instructions in #11 with 59.0.3071.86, see attached graph for an example.

Deleted: Screenshot from 2017-06-26 11:51:29.png 30.0 KB

	Screenshot from 2017-06-26 11:51:29.png 30.0 KB View Download

Hi holmer, thank you for looking into this. It seems to not be reproducible at low bitrates. Please try again, but as step 1.5, enter 1000 in the Video Bitrate field.

With 60.0.3112.40 I still can't reproduce with step 1.5.

Deleted: Screen Shot 2017-06-27 at 10.00.49.png 71.1 KB

	Screen Shot 2017-06-27 at 10.00.49.png 71.1 KB View Download

Unless I'm reading your screenshot wrong, it seems you reproduced it. You're transmitting ~half of the requested bitrate.

Ok, I must have misunderstood. I thought it wasn't possible to set a max bitrate, but the issue is that the encoder only utilizes 500 kbps out of the 1000 available.

Change to 2000 seems to give us 1000, so there appears to be some division by 2 going on somewhere.

Yep, that's what I was thinking. Let's hope it's a simple fix. If there's anything else I can provide, please let me know.

Just checking in here. Now that it's been reproduced, can it be triaged? Thank you!

It looks like this was successfully reproduced, so I'm going to assign this to holmer@. Feel free to reassign if you are not the right person to handle this :)

I'm still doing some testing, but this bug does not seem to appear when I set the video resolution to 720p. It was 360p before. ¯\_(ツ)_/¯

Has anyone had a chance to take a look at this? Thanks.

I have taken a deeper look, and AFAICT the target bitrate is correct all the way to vp8_impl.cc. The bitrate measured by media_optimization.cc, rtp_sender.cc and send_statistics_proxy.cc however indicate that what's coming out of the encoder is only half of the target bitrate. I don't see how this relates to TCP, but on the other hand I haven't tested this page with UDP, so maybe it's unrelated. Either way it seems wrong.

Erik/Rasmus, do you have any ideas? 

Could there be some issue with nack bitrate limit? Protection is allowed to use up to 50% of available (target?) bitrate iirc.

Not sure. From my logs, the actual target bitrate set in vp8_impl.cc is 500 kbps, while the bitrate coming out of libvpx seems to be around 250 kbps (as indicated by media_optimization.cc, MediaOptimization::UpdateWithEncodedData).

Hm, doesn't sound like protection bitrate is the issue then, rather something in the encoder itself. But why would that behave differently for tcp?!

Do you have a solid repro case?

It's easily reproduced by following the link and simply pressing publish. Look at webrtc-internals, which will show that encoder target bitate is 500, but the encoder output is 250.

Changing the hard coded bitrate to 1000 gives you encoder output of 500.

Note that I have never tried with UDP on this page, so perhaps there's something unrelated to TCP going wrong.

Can't repro this. Looking at some debug traces though, I have this output:

@New rate allocation: BitrateAllocation [ [500000] ], fps = 60
@New rate allocation: BitrateAllocation [ [500000] ], fps = 29
@New rate allocation: BitrateAllocation [ [500000] ], fps = 30

This makes me suspect that this bug was fixed here:
https://bugs.chromium.org/p/webrtc/issues/detail?id=7664&desc=2

With TCP, is it less likely we would get a new bitrate estimate? If so, the first (default and incorrect) framerate would probably not be updated to a correct value. And so would cause the encoder to produce frames with incorrect size.

Can you check with M61 if this is fixed for you?

This seems to be fixed in Version 62.0.3174.0 (Official Build) canary (64-bit)

Attached are screenshots for before the fix:
Version 60.0.3112.78 (Official Build) (64-bit)
vs. with the fix:
Version 61.0.3163.25 (Official Build) dev (64-bit)

Deleted: chrome-stable-half-bitrate-bug.png 3.8 KB

	chrome-stable-half-bitrate-bug.png 3.8 KB View Download

Deleted: chrome-unstable-fixed.png 4.4 KB

	chrome-unstable-fixed.png 4.4 KB View Download

Thanks! I'll mark this bug as fixed then.

Thank you all.