| Age | Commit message (Collapse) | Author |
|---|
|
If the start bitrate is set twice, it will be set to the sum of the start
bitrates of the currently registered bitrate observers, or left unchanged
if the current estimate actually is greater than the sum.
BUG=3503
R=henrik.lundin@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15839004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@6491 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
This CL brought to you by:
$ for d in $(for f in $(git ls-files '*gyp' '*gypi'); do dirname $f; done|sort|uniq|grep -v '^\.$'); do echo -e "\n# These are for the common case of adding or renaming files. If you're doing\n# structural changes, please get a review from a reviewer in this file.\nper-file *.gyp=*\nper-file *.gypi=*" >> $d/OWNERS; done
$ for d in $(for f in $(git ls-files '*gyp' '*gypi'); do dirname $f; done|sort|uniq|grep -v '^\.$'); do git add $d/OWNERS; done
(and then removed the talk/ impact)
R=niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11969004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@5903 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
BUG=3153
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11069005
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@5851 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
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@5794 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
capacity is distributed among outgoing video streams. For example, this can be used to reserve space for audio streams.
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10499004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@5791 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
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/webrtc@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
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/webrtc@5775 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
- 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/webrtc@5752 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
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/webrtc@5749 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
R=stefan@webrtc.org
BUG=3065
Review URL: https://webrtc-codereview.appspot.com/10029005
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@5710 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
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/webrtc@5646 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
Changing to using strategy classes rather than having two different
derived classes of BitrateControllerImpl. This enables run-time switching
of the strategy, which is now possible through a new API. The reason is
that it must fit the current design of ViE.
BUG=2436
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2789004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@5028 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
This CL implements an alternative to the bitrate clamping that is done
in BitrateControllerImpl. The default behavior is unchanged, but if
the new algorithm is enabled the behavior is as follows:
When the new bitrate is lower than the sum of min bitrates, the
algorithm will give each observer up to its min bitrate, one
observer at a time, until the bitrate budget is depleted. Thus,
with this change, some observers may get less than their min bitrate,
or even zero.
Unit tests are implemented.
Also fixing two old lint warnings in the affected files.
This change is related to the auto-muter feature.
BUG=2436
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2439005
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@5007 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
BUG=1662
TEST=compile on trybots
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2301004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@4854 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
Use a weighted average of fraction loss for bandwidth estimation.
TEST=trybots and vie_auto_test --automated
BUG=1811
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2198004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@4762 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
BUG=163
R=pwestin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1903004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@4442 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
BUG=1662
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1787004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@4349 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
This CL will lower the number of test targets in WebRTC by:
Add common_audio_unittests and merge the following targets into it (copied from http://review.webrtc.org/1584006):
* resampler_unittests
* signal_processing_unittests
* vad_unittests
Merge into modules_unittests:
* bitrate_controller_unittests
* desktop_capture_unittests
* media_file_unittests
* remote_bitrate_estimator_unittests
* rtp_rtcp_unittests
* paced_sender_unittests
Merge into test_support_unittests:
* channel_transport_unittests
channel_transport.gyp was also removed in favor for test.gyp.
I had to remove a main method from rtcp_format_remb_unittest.cc
since it caused the fileutils.h code to not be able to find the
right project root path in ordrer to provide correct paths
to test files.
Buildbot configuration update will be synced with the commit of this CL.
TEST=trybots
BUG=1843
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1639004
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@4213 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
BUG=1655
Review URL: https://webrtc-codereview.appspot.com/1326005
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@3857 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
Mostly disabling warnings in the gyp files.
BUG=1348
BUG=http://crbug.com/166496
BUG=http://crbug.com/167187
Review URL: https://webrtc-codereview.appspot.com/1063011
Patch from Justin Schuh <jschuh@chromium.org>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@3423 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
This will remove all usage of '<(library)' in all webrtc gyp files.
Review URL: https://webrtc-codereview.appspot.com/1049005
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@3392 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
BUG=
Review URL: https://webrtc-codereview.appspot.com/965019
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@3087 4adac7df-926f-26a2-2b94-8c16560cd09d
|
|
TBR=niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/915006
git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@2963 4adac7df-926f-26a2-2b94-8c16560cd09d
|
