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/bitrate_controller_impl.h
|
3c089d751ede283e21e186885eaf705c3257ccd2 |
|
16-Sep-2015 |
henrikg <henrikg@webrtc.org> |
Add RTC_ prefix to contructormagic 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. * DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN * DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN * DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS Related CL: https://codereview.webrtc.org/1335923002/ BUG=chromium:468375 NOTRY=true Review URL: https://codereview.webrtc.org/1345433002 Cr-Commit-Position: refs/heads/master@{#9953}
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
867fb5224e1ba6a1c2cd523c005499a93ed61a08 |
|
03-Aug-2015 |
sprang <sprang@webrtc.org> |
Add support for transport wide sequence numbers Also refactor packet router to use a map rather than iterate over all rtp modules for each packet sent. BUG=webrtc:4311 Review URL: https://codereview.webrtc.org/1247293002 Cr-Commit-Position: refs/heads/master@{#9670}
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
8bd2f40a8c25b6c71790e49f202593ce61e09cca |
|
16-Mar-2015 |
sprang@webrtc.org <sprang@webrtc.org> |
Remove code related to REMB suppressor experiment. Stats indicate this isn't helping. Ditching the whole thing. BUG=4082 R=mflodman@webrtc.org Review URL: https://webrtc-codereview.appspot.com/47569004 Cr-Commit-Position: refs/heads/master@{#8734} git-svn-id: http://webrtc.googlecode.com/svn/trunk@8734 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
14665ff7d4024d07e58622f498b23fd980001871 |
|
04-Mar-2015 |
kjellander@webrtc.org <kjellander@webrtc.org> |
Roll chromium_revision e144d30..6fdb142 (318658:318841) + remove OVERRIDE macro Clang version changed 223108:230914 Details: https://chromium.googlesource.com/chromium/src/+/e144d30..6fdb142/tools/clang/scripts/update.sh Removes the OVERRIDE macro defined in: * webrtc/base/common.h * webrtc/typedefs.h The majority of the source changes were done by running this in src/: perl -0pi -e "s/virtual\s([^({;]*(\([^({;]*\)[^({;]*))(OVERRIDE|override)/\1override/sg" `find {talk,webrtc} -name "*.h" -o -name "*.cc*" -o -name "*.mm*"` which converted all: virtual Foo() OVERRIDE functions to: Foo() override Then I manually edited: * talk/media/webrtc/fakewebrtccommon.h * webrtc/test/fake_common.h Remaining uses of OVERRIDE was fixed by search+replace. Manual edits were done to fix virtual destructors that were overriding inherited ones. Finally a build error related to the pure virtual definitions of Read, Write and Rewind in common_types.h required a bit of refactoring in: * webrtc/common_types.cc * webrtc/common_types.h * webrtc/system_wrappers/interface/file_wrapper.h * webrtc/system_wrappers/source/file_impl.cc This roll should make it possible for us to finally re-enable deadlock detection for TSan on the buildbots. BUG=4106 R=pbos@webrtc.org, tommi@webrtc.org Review URL: https://webrtc-codereview.appspot.com/41069004 Cr-Commit-Position: refs/heads/master@{#8596} git-svn-id: http://webrtc.googlecode.com/svn/trunk@8596 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
00b8f6b3643332cce1ee711715f7fbb824d793ca |
|
26-Feb-2015 |
kwiberg@webrtc.org <kwiberg@webrtc.org> |
Use base/scoped_ptr.h; system_wrappers/interface/scoped_ptr.h is going away BUG= R=andrew@webrtc.org Review URL: https://webrtc-codereview.appspot.com/36229004 Cr-Commit-Position: refs/heads/master@{#8517} git-svn-id: http://webrtc.googlecode.com/svn/trunk@8517 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
9b79197c8041c44912c7e97f2c5ea67c5e6d1cab |
|
18-Dec-2014 |
sprang@webrtc.org <sprang@webrtc.org> |
Suppress REMB in bitrate ctrl if it seems lika a short network glitch. BUG=4082 R=stefan@webrtc.org Review URL: https://webrtc-codereview.appspot.com/37369004 git-svn-id: http://webrtc.googlecode.com/svn/trunk@7948 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
0b1534c52eab79372557a6d81aaf4dd9407f55d3 |
|
15-Dec-2014 |
pkasting@chromium.org <pkasting@chromium.org> |
Use int64_t for milliseconds more often, primarily for TimeUntilNextProcess. This fixes a variety of MSVC warnings about value truncations when implicitly storing the 64-bit values we get back from e.g. TimeTicks in 32-bit objects, and removes the need for a number of explicit casts. This also moves a number of constants so they're declared right where they're used, which is easier to read and maintain, and makes some of them of integral type rather than using the "enum hack". BUG=chromium:81439 TEST=none R=tommi@webrtc.org Review URL: https://webrtc-codereview.appspot.com/33649004 git-svn-id: http://webrtc.googlecode.com/svn/trunk@7905 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
4e65602886830e19d2d76d4c07dc22c5c2106e8d |
|
26-Mar-2014 |
solenberg@webrtc.org <solenberg@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Add API to allow deducting bitrate from incoming estimates before the 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@5791 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
b56d0e383e62f74651aa78b9c2857e1b57a8729b |
|
24-Oct-2013 |
henrik.lundin@webrtc.org <henrik.lundin@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Change the low-bitrate handling in BitrateControllerImpl 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@5028 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
29dd0de5b35f757289895b7af7c9c5905878270f |
|
21-Oct-2013 |
henrik.lundin@webrtc.org <henrik.lundin@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Changing the bitrate clamping in BitrateControllerImpl 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@5007 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
4fac8a469921df98e2bdc644b442600bddba2b47 |
|
31-Jul-2013 |
pbos@webrtc.org <pbos@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> |
Fix some chromium-style warnings in webrtc/modules/bitrate_controller/ BUG=163 R=pwestin@webrtc.org Review URL: https://webrtc-codereview.appspot.com/1903004 git-svn-id: http://webrtc.googlecode.com/svn/trunk@4442 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/webrtc/modules/bitrate_controller/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|
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/bitrate_controller_impl.h
|