From now on it is expected that code linking system_wrappers.gyp:system_wrappers
provides an implementation for field_trial API or links with the default one in
system_wrappers.gyp:field_trial_default.
Note: Since there is no use of webrtc::field_trial API inside webrtc this CL on
itself does not forces the clients to actually define it. It however lays the
API and updates the gyp rules to link with so that it is ready to use.
Tested: Introduced a use of field trial in system wrappers and make sure all
bots were building successfully.
BUG=crbug/367114
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14489004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6147 4adac7df-926f-26a2-2b94-8c16560cd09d
With the switch recipes on the buildbots and the deprecation of
the custom script at
https://code.google.com/p/webrtc/source/browse/trunk/webrtc/test/buildbot_tests.py
these tests will start failing when Chromium's runtest.py is passing
--brave-new-test-launcher --test-launcher-bot-mode
to the test.
A similar change was made for most of WebRTC's tests (that depends on
the test_support_main target) in
https://webrtc-codereview.appspot.com/2222005
BUG=chromium:346198
TEST=Successfully launched the executables on Linux and Mac using:
out/Release/voe_auto_test --brave-new-test-launcher --test-launcher-bot-mode --automated --test-launcher-summary-output=/tmp/tmpwhx6Zz
out/Release/vie_auto_test --brave-new-test-launcher --test-launcher-bot-mode --automated --capture_test_ensure_resolution_alignment_in_capture_device=false --test-launcher-summary-output=/tmp/tmpwhx6Zz
R=henrika@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/13499004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6135 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
- An RTX packet with no payload should be dropped prior to parsing RTX header since it doesn't have an RTX header. This can for example happen when sending padding-only packets over the RTX stream.
- The retransmit code path when the pacer is disabled doesn't properly update the abs-send-time and ts-offset header extensions.
TEST=trybots
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5728 4adac7df-926f-26a2-2b94-8c16560cd09d
New interface uses two bitrates (max/min). The pace multiplier is also
removed from the interface and instead utilized outside. Min bitrate
will be filled with padding if there's not enough media to transmit.
Also fixes a bug in minimum transmission bitrate that made it ignore
REMBs. A regression test has been added to catch it.
BUG=3014
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10059004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5723 4adac7df-926f-26a2-2b94-8c16560cd09d
The deadlock can happen when using HW encoder. HW encoder calls
the encode complete callback on libjingle worker thread instead
of ViECaptureThread. The capture thread can hold VieEncoder::|data_cs_|
and wait for ModuleRtpRtcpImpl::|critical_section_module_ptrs_|.
When libjingle worker thread runs encode complete callback, it
can hold ModuleRtpRtcpImpl::|critical_section_module_ptrs_| and
wait for VieEncoder::|data_cs_|.
|default_rtp_rtcp_| is not guarded by |data_cs|. So move it out of
the critical section to avoid the deadlock.
BUG=chromium:352567
TEST=Run apprtc loopback on CrOS.
Run apprtc between CrOS and Linux.
Run vie_auto_test.
R=henrik.lundin@webrtc.org, pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10039004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5721 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
