This is a step on the way to have variable bitrate for audio and is
intended to be as much of a no-op as possible.
BUG=webrtc:5079
Review URL: https://codereview.webrtc.org/1441673002
Cr-Commit-Position: refs/heads/master@{#10630}
ChannelGroup::OnNetWorkChanged() should not configure the pacer to send
a lower bitrate than what bitrate_allocator has actually allocated (may
be the case if min_bitrate is enforced, for instance).
BUG=
Review URL: https://codereview.webrtc.org/1413663004
Cr-Commit-Position: refs/heads/master@{#10519}
This changes the following module directories:
* webrtc/modules/audio_conference_mixer/interface
* webrtc/modules/interface
* webrtc/modules/media_file/interface
* webrtc/modules/rtp_rtcp/interface
* webrtc/modules/utility/interface
To avoid breaking downstream, I followed this recipe:
1. Copy the interface dir to a new sibling directory: include
2. Update the header guards in the include directory to match the style guide.
3. Update the header guards in the interface directory to match the ones in include. This is required to avoid getting redefinitions in the not-yet-updated downstream code.
4. Add a pragma warning in the header files in the interface dir. Example:
#pragma message("WARNING: webrtc/modules/interface is DEPRECATED; "
"use webrtc/modules/include")
5. Search for all source references to webrtc/modules/interface and update them to webrtc/modules/include (*.c*,*.h,*.mm,*.S)
6. Update all GYP+GN files. This required manual inspection since many subdirectories of webrtc/modules referenced the interface dir using ../interface etc(*.gyp*,*.gn*)
BUG=5095
TESTED=Passing compile-trybots with --clobber flag:
git cl try --clobber --bot=win_compile_rel --bot=linux_compile_rel --bot=android_compile_rel --bot=mac_compile_rel --bot=ios_rel -m tryserver.webrtc
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1417683006 .
Cr-Commit-Position: refs/heads/master@{#10500}
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}
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}
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}
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}
Remove start_bitrate_bps which is no longer used and return the current
allocated bitrate instead of having it as an out parameter, removing the
previous return value which is no longer used.
Permits removing bitrate controller usage from ViEEncoder.
BUG=webrtc:1695
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1343783006 .
Cr-Commit-Position: refs/heads/master@{#9942}
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}
Add pylintrc file based on
https://code.google.com/p/chromium/codesearch#chromium/src/tools/perf/pylintrc
bit tightened up quite a bit (the one in depot_tools is far
more relaxed).
Remove a few excluded directories from pylint check and fixed/
suppressed all warnings generated.
Add GN format check + formatted all GN files using 'gn format'.
Cleanup redundant rules in tools/PRESUBMIT.py
TESTED=Ran 'git cl presubmit -vv', fixed the PyLint violations.
Ran it again with a modification in webrtc/build/webrtc.gni, formatted
all the GN files and ran it again.
R=henrika@webrtc.org, phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50069004
Cr-Commit-Position: refs/heads/master@{#9274}
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}
Clang version changed 223108:230914
Details: 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
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
Now that WebRTC has rolled the chromium_revision past
http://crrev.com/284372 in r6784, clang has become the
default compiler. Since WebRTC standalone code doesn't
yet compile the Chromium Clang plugins enabled, this CL
disables them for the parts of the code that doesn't yet pass
compilation with them enabled.
The buildbots are using Goma which is not yet switched
over to Clang by default. That's why they're not red yet.
BUG=163
TEST=Passing compile locally on Linux using:
gn gen out/Debug --args="build_with_chromium=false is_debug=true" && ninja
-C out/Debug
gn gen out/Release --args="build_with_chromium=false is_debug=false" && ninja
-C out/Release
gn gen out/Default --args="build_with_chromium=false os=\"android\" cpu_arch=\"arm\" arm_version=7" && ninja -C out/Default
R=brettw@chromium.org
Review URL: https://webrtc-codereview.appspot.com/16279004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6966 4adac7df-926f-26a2-2b94-8c16560cd09d
This should work as a foundation for all the work that is
left to do to make the parts of WebRTC that Chromium uses
to build with GN.
I implemented some the smaller modules myself in this CL.
The remaining work (TODO's in the .gn files) will be distributed
to various team members.
I'm adding myself to OWNERS files for BUILD.gn files in all the
directories where I'm adding a BUILD.gn file.
BUG=3441
TEST=
Successful compilation of WebRTC as standalone:
gn gen out/Default --args="build_with_chromium=false" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false is_clang=true clang_use_chrome_plugins=false" && ninja -C out/Default
I built successfully from a Chromium checkout (with
https://codereview.chromium.org/321313006/ applied) using:
gn gen out/Default && ninja -C out/Default webrtc
R=brettw@chromium.org, niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/13749004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6523 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@5903 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@5794 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/10529004TBR=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
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
- 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
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
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
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
