| 53805324c0fa904d796cc0b333868c591f2c5f2c |
|
21-Dec-2015 |
asapersson <asapersson@webrtc.org> |
Rename RTC_HISTOGRAM_* macros to RTC_HISTOGRAM_*_SPARSE_* to indicate that these are for infrequent updates.
This implementation will be replaced by a faster one and sparse will be removed.
BUG=webrtc:5283
Review URL: https://codereview.webrtc.org/1530913002
Cr-Commit-Position: refs/heads/master@{#11099}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 7c704b82893bbe7fc206b004fb9dfe6e69a986ef |
|
04-Dec-2015 |
Peter Boström <pbos@webrtc.org> |
Use webrtc/base/logging.h in stefan@'s ownership.
Replaces system_wrappers' logging in call/, bitrate_controller/, pacing/
and remote_bitrate_estimator/.
BUG=webrtc:5118
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1484503002 .
Cr-Commit-Position: refs/heads/master@{#10896}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 006d93d3c679ffd15223c327d649066a72400639 |
|
05-Nov-2015 |
terelius <terelius@webrtc.org> |
Added protobuf message for loss-based BWE events, and wired it up to the send side bandwidth estimator.
BUG=
Review URL: https://codereview.webrtc.org/1411673003
Cr-Commit-Position: refs/heads/master@{#10531}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 98f53510b222f71fdd8b799b2f33737ceeb28c61 |
|
28-Oct-2015 |
Henrik Kjellander <kjellander@webrtc.org> |
system_wrappers: rename interface -> include
BUG=webrtc:5095
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1413333002 .
Cr-Commit-Position: refs/heads/master@{#10438}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| b7edb88ae2bb65b3b7ce3be31dd708470baa3575 |
|
22-Oct-2015 |
pbos <pbos@webrtc.org> |
Prevent BWE rampdowns without new loss reports.
Before this change, UpdateEstimate would repeatedly decrease bitrate
even though there's no fresh corresponding RTCP loss report, triggering
multiple reactions to a single indication of high packet loss.
BUG=webrtc:5101
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1417723005
Cr-Commit-Position: refs/heads/master@{#10374}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 757077b34e0cbcf0f6c5a3a1ba9303cb1d153a47 |
|
16-Oct-2015 |
gaetano.carlucci <gaetano.carlucci@gmail.com> |
Removing the TFRC Rate Control
This removes the TRFC rate control which does not introduce any help in the
computation of the sending rate.
BUG=5083
Review URL: https://codereview.webrtc.org/1383813003
Cr-Commit-Position: refs/heads/master@{#10299}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 91d6edef35e7275879c30ce16ecb8b6dc73c6e4a |
|
17-Sep-2015 |
henrikg <henrikg@webrtc.org> |
Add RTC_ prefix to (D)CHECKs and related macros.
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| b6b0b9268ec22ef055bf1df7b2439e6babd1dac0 |
|
04-Sep-2015 |
stefan <stefan@webrtc.org> |
Rate limit the low bandwidth / min bitrate warning to once every 10 seconds.
R=terelius@webrtc.org
Review URL: https://codereview.webrtc.org/1320763003
Cr-Commit-Position: refs/heads/master@{#9855}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| e59041672283a28bde0b043c0c2bc198272f82e1 |
|
26-Mar-2015 |
Stefan Holmer <holmer@google.com> |
Moving the pacer and the pacer thread to ChannelGroup.
This means all channels within the same group will share the same pacing queue and scheduler. It also means padding will be computed and sent by a single pacer. To accomplish this I also introduce a PacketRouter which finds the RTP module which owns the packet to be paced out.
BUG=4323
R=mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45549004
Cr-Commit-Position: refs/heads/master@{#8864}
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 792f1a14e2b62382c5c6080d0b8fdc5c89d27bc6 |
|
04-Mar-2015 |
stefan@webrtc.org <stefan@webrtc.org> |
Break out allocation from BitrateController into a BitrateAllocator.
This also refactors some of the padding and allocation code in ViEEncoder, and
makes ChannelGroup a simple forwarder from BitrateController to
BitrateAllocator.
This CL is part of a bigger picture, see https://review.webrtc.org/35319004/ for
details.
BUG=4323
R=mflodman@webrtc.org, pbos@webrtc.org, sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44399004
Cr-Commit-Position: refs/heads/master@{#8595}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8595 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 0e8bf6c4d32a164341623d46ae04aefc346a73ca |
|
03-Feb-2015 |
stefan@webrtc.org <stefan@webrtc.org> |
Enable bitrate probing by default.
Results from the experiment were all positive.
BUG=crbug:425925
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38829004
Cr-Commit-Position: refs/heads/master@{#8231}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8231 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 474e36e6232a6d85238023acdd5067953f9348d2 |
|
19-Jan-2015 |
stefan@webrtc.org <stefan@webrtc.org> |
Add UMA stats for tracking the time it takes to reach a BWE of 500, 1000 and 2000 kbps.
The previous CL was reverted for two reasons:
- Added a static initializer because std::string.
- Landed before the corresponding chromium CL, which has now been landed.
BUG=crbug:425925
R=asapersson@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39549004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8094 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| a1aea10af2926290cdad55f97b4f6e6a4298082e |
|
16-Jan-2015 |
stefan@webrtc.org <stefan@webrtc.org> |
Revert r8076 "Add UMA stats for tracking the time it takes to reach a BWE of 500, 1000 and 2000 kbps."
TBR=perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37629004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8085 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 3e42a8a56acaf48cccbe82003bbc1d0723a54732 |
|
15-Jan-2015 |
stefan@webrtc.org <stefan@webrtc.org> |
Add UMA stats for tracking the time it takes to reach a BWE of 500, 1000 and 2000 kbps.
BUG=crbug:425925
R=asapersson@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8076 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 16825b1a828bb4ff40f7682040e43a239b7b8ca3 |
|
12-Jan-2015 |
pkasting@chromium.org <pkasting@chromium.org> |
Use int64_t more consistently for times, in particular for RTT values.
Existing code was inconsistent about whether to use uint16_t, int, unsigned int,
or uint32_t, and sometimes silently truncated one to another, or truncated
int64_t. Because most core time-handling functions use int64_t, being
consistent about using int64_t unless otherwise necessary minimizes the number
of explicit or implicit casts.
BUG=chromium:81439
TEST=none
R=henrik.lundin@webrtc.org, holmer@google.com, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31349004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8045 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| edeea91803eac26f6a229e88a7045797d2af61b7 |
|
08-Dec-2014 |
stefan@webrtc.org <stefan@webrtc.org> |
Change all system clock types to int64_t in bitrate_controller.
They are both compared to int64_t types inside the class, and is being called
with int64_t types. Could possibly cause bugs.
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7832 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 83d4804a50a9b8ee5e029ef1cb62659611a03d7b |
|
10-Nov-2014 |
stefan@webrtc.org <stefan@webrtc.org> |
Put send-side bwe probing under finch experiment.
BUG=crbug/425925
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26079004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7668 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| db26247a9b8eda2c6313f5bdadf374526b070582 |
|
04-Nov-2014 |
stefan@webrtc.org <stefan@webrtc.org> |
Add UMA for measuring the diff between the BWE at 2 seconds compared to the BWE at 20 seconds when the BWE should have converged.
BUG=crbug/425925
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/30819005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7620 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 548b228c91b446713eded8ca1858c32d3597ea5c |
|
03-Nov-2014 |
stefan@webrtc.org <stefan@webrtc.org> |
Add UMA metrics for the initial (after two seconds) packet loss, round-trip time and bandwidth estimate of a WebRTC call.
BUG=crbug/425925
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31899004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7593 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 82462aade0ad3fbe76284ac294b41fb500a1d2f8 |
|
23-Oct-2014 |
stefan@webrtc.org <stefan@webrtc.org> |
Adds support for sending first set of packets at increasingly higher bitrates to probe the link and faster ramp up to a high bitrate.
Also wires up a finch experiment to control this.
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/30639004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7505 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 36947bb635ccc92209497c80494c21c86c25977c |
|
07-Apr-2014 |
andresp@webrtc.org <andresp@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Fix logging calls in bitrate_controller module.
BUG=3153
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11069005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5851 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 44caf01c34d4fddec039f917c83fed7e0ce977b2 |
|
26-Mar-2014 |
andresp@webrtc.org <andresp@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Re-submit: rev5775
Modify bitrate controller to update bitrate based on process call and not
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5794 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 6cd201cf31dc8e50bf815139b0c9fdc83d3ba2bf |
|
25-Mar-2014 |
andrew@webrtc.org <andrew@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Revert 5775 "Modify bitrate controller to update bitrate based o..."
This triggered an occasional TSAN failure in
CallTest.ReceivesPliAndRecoversWithNack e.g.:
http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio
I managed to reproduce this locally and verified that reverting this CL
corrected it.
> Modify bitrate controller to update bitrate based on process call and not
> only whenever a RTCP receiver block is received.
>
> Additionally:
> Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
>
> Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
>
> Did not touch decrease logic, however since it can be triggered more often it
> may decrease much faster and closer to the original written cap of once every
> 300ms + rtt.
>
> Note:
> rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
> bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
>
> BUG=3065
> R=stefan@webrtc.org, mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/10529004
TBR=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10079005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| da07737e68e23e283466ae21965e43edfe621a12 |
|
25-Mar-2014 |
andresp@webrtc.org <andresp@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Modify bitrate controller to update bitrate based on process call and not
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5775 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 07bc7344595e9cb3a3039eaffcb7a3ec2ca72928 |
|
21-Mar-2014 |
andresp@webrtc.org <andresp@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Refactor in BitrateController module.
- Move condition of 0 bps as max meaning 1gbps from SendSideBandwidthEstimation to BitrateController.
- Remove condition on bitrate=0 meaning bandwidth estimation off as that could only happen when no observers existed
and in which case the estimation would be ignored.
- Add MaybeTriggerOnNetworkChanged which only runs rate allocation if any of the dependent variables has changed
thus allowing to remove many of the bool returns that try to indicate if the estimation has changed which would not
be aware if the observers have changed.
- SendSideBandwidthEstimation now has a UpdateBitrate and has clear code paths to which calls update bitrate.
- Changes in enforce_min_bitrate so the 10kbps min is set from the BitrateController and not from the outside this keep valid as observers are changed.
R=henrik.lundin@webrtc.org, stefan@webrtc.org
BUG=3065
Review URL: https://webrtc-codereview.appspot.com/10189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5752 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 16b75c2c7aeeefce614e5966d90d4e648f49777c |
|
21-Mar-2014 |
andresp@webrtc.org <andresp@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Remove locks in SendSideBandwidthEstimation since those are only accessed while owning locks in
BitrateControllerImpl (excluding AvailableBandwidth).
+ Refactor BitrateController logic around LowRate allocation so access to SendSideBandwidthEstimation
is clear.
+ Refactor NormalRateAllocation away from OnNetworkChange.
+ Annotate BitrateController locks.
R=henrik.lundin@webrtc.org, stefan@webrtc.org
BUG=3065
Review URL: https://webrtc-codereview.appspot.com/10129004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5749 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 4e69f782b0e67ade5b68657c6f22b8c5b61f3a4d |
|
17-Mar-2014 |
andresp@webrtc.org <andresp@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Small refactor on send_side_bandwidth_estimation.
R=stefan@webrtc.org
BUG=3065
Review URL: https://webrtc-codereview.appspot.com/10029005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5710 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 845862f2794a448f203da48ae27f0deb0cb69dc1 |
|
06-Mar-2014 |
henrik.lundin@webrtc.org <henrik.lundin@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Adding a new ramp-up-down-up test
The new test is based upon the exisiting rampup test, but also adds
a low-rate period. The main purpose of the test is to verify the
SuspendBelowMinBitrate functionality, which must be enabled for the
test to pass.
The CL also adds a change to the min bitrate in the send-side bandwidth
estimator when SuspendBelowMinBitrate is enabled.
An anonymous namespace is added around the StreamObserver classes
in the test to avoid silent linker conflicts that could happen
otherwise.
Note: this CL depends on https://webrtc-codereview.appspot.com/9049004/
BUG=2636
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9059004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5646 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 2e10b8e4a05c041a3c39ddc7499bdffdb67999fa |
|
16-Jul-2013 |
pbos@webrtc.org <pbos@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Include files from webrtc/.. paths in bitrate_controller/.
BUG=1662
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1787004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4349 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|
| 14b43beb7ce4440b30dcea31196de5b4a529cb6b |
|
22-Oct-2012 |
andrew@webrtc.org <andrew@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Move src/ -> webrtc/
TBR=niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/915006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@2963 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
|