This CL adds full stack tests that are used to measure the performance
of H264 with and without FlexFEC. In order to not increase the bot
run time, the CL also reduces the test time to 45 secs. This should
be OK, since the BWE is faster to ramp up nowadays.
Due to the test time change, there may be some performance alerts.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2499273002
Cr-Commit-Position: refs/heads/master@{#15118}
Will be used by full stack tests and video_loopback.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2500373002
Cr-Commit-Position: refs/heads/master@{#15114}
Just returns the configuration the PC was constructed with, or the last
one passed into SetConfiguration.
BUG=chromium:587453
Review-Url: https://codereview.webrtc.org/2504103002
Cr-Commit-Position: refs/heads/master@{#15111}
This is because:
1) The environment variables were still around when the test was executed.
2) gtest-parallel executes only one test at a time.
So when the test was invoked from a shard different than the 0th one, for example as:
./something_unittests --gtest_filter=Test.Name
It read the environment variables, and the environment variables together with the gtest_filter flag, told it that there were several shards, but only one test to be run, so if it wasn't the 0th shard, it wouldn't run the test at all.
This is fixed by erasing the environment variables once read.
Also change swarming-related flag names to fit the rest of the flags and validate their values.
NOTRY=True
BUG=chromium:497757, chromium:664425
TBR=pbos@webrtc.org, kjellander@webrtc.org
Review-Url: https://codereview.webrtc.org/2505093003
Cr-Commit-Position: refs/heads/master@{#15110}
Previously AlrDetector was measuring amount of data sent in each 100ms
interval and would enter ALR mode after 5 consecutive intervals when
average bandwidth usage doesn't exceed 30% of the current estimate
estimate. This meant that an application that uses only slightely more
than 6% of total bandwidth may stay out of ALR mode, e.g. if it sends
a frame of size BW*30ms every 0.5 seconds. 100ms is too short interval
to average over, particularly when frame-rate falls below 10fps.
With this change AlrDetector averages BW usage over last 500ms. It then
enters ALR state when usage falls below 30% and exits it when usage
exceeds 50%.
BUG=webrtc:6332
R=philipel@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2503643003 .
Cr-Commit-Position: refs/heads/master@{#15109}
This is yet another reland of https://codereview.webrtc.org/2434073003/
including two fixes:
1. SimulcastRateAllocator did not handle the screenshare settings properly for numSimulcastStreams = 1. Additional test case was added for that.
2. In VideoSender, when rate allocation is updated after setting a new VideoCodec config, only update the state of the EncoderParameters, but don't actually run SetRateAllocation on the encoder itself. This caused some problems upstreams.
Please review only the changes after patch set 1.
Original description:
Extract bitrate allocation of spatial/temporal layers out of codec impl.
This CL makes a number of intervowen changes:
* Add BitrateAllocation struct, that contains a codec independent view
of how the target bitrate is distributed over spatial and temporal
layers.
* Adds the BitrateAllocator interface, which takes a bitrate and frame
rate and produces a BitrateAllocation.
* A default (non layered) implementation is added, and
SimulcastRateAllocator is extended to fully handle VP8 allocation.
This includes capturing TemporalLayer instances created by the
encoder.
* ViEEncoder now owns both the bitrate allocator and the temporal layer
factories for VP8. This allows allocation to happen fully outside of
the encoder implementation.
This refactoring will make it possible for ViEEncoder to signal the
full picture of target bitrates to the RTCP module.
BUG=webrtc:6301
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2510583002 .
Cr-Commit-Position: refs/heads/master@{#15105}
The peer connection loopback test could catch regressions too, but it's
too slow to run on downstream ARM emulators. I'm adding a test here
that just makes sure we can load the JNI and init audio/video engines
in WebRTC.
This test overlaps in functionality with the existing tests,
but we need it anyway since all existing tests are too timing-sensitive.
Removes resources from the test; they're awkward downstream and we
don't really need them anyway.
BUG=b/32820229
Review-Url: https://codereview.webrtc.org/2506603002
Cr-Commit-Position: refs/heads/master@{#15101}
Reason for revert:
It broke downstream test.
Original issue's description:
> Start probes only after network is connected.
>
> Previously ProbeController was starting probing as soon as SetBitrates()
> is called. As result these probes would often timeout while connection
> is being established. Now ProbeController receives notifications about
> network route changes. This allows to start probing only when transport
> is connected. This also makes it possible to restart probing whenever
> transport route changes (will be done in a separate change).
>
> BUG=webrtc:6332
>
> Committed: https://crrev.com/5c99c76255ee7bface3c742c25fb5617748ac86e
> Cr-Commit-Position: refs/heads/master@{#15094}
TBR=philipel@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2504783002
Cr-Commit-Position: refs/heads/master@{#15098}
If a checkout has been created but haven't yet executed gclient
runhooks, running setup_links.py --clean-only will fail if
the Chromium checkout isn't yet synced. This can make bots
end up in a bad state since we now clean all links before running
bot_update. Relaxing this error solves that problem.
BUG=chromium:663278
TBR=ehmaldonado@webrtc.org
NOTRY=True
Review URL: https://codereview.webrtc.org/2496323004 .
Cr-Commit-Position: refs/heads/master@{#15097}
Previously ProbeController was starting probing as soon as SetBitrates()
is called. As result these probes would often timeout while connection
is being established. Now ProbeController receives notifications about
network route changes. This allows to start probing only when transport
is connected. This also makes it possible to restart probing whenever
transport route changes (will be done in a separate change).
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2458863002
Cr-Commit-Position: refs/heads/master@{#15094}
The old API CGScreenRegisterMoveCallback returned update rects in desktop
coordinates [secondary display has an origin != 0,0]. The new CGDisplayStream
API returns update rects in display coordinates [origin == 0,0]. Translating the
update rect based on the display's position on the desktop is now incorrect.
BUG=webrtc:6702
Review-Url: https://codereview.webrtc.org/2496413002
Cr-Commit-Position: refs/heads/master@{#15092}
This is initial work to get the stats working for FlexFEC.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2498393002
Cr-Commit-Position: refs/heads/master@{#15089}
This is needed for the following coming tests: VideoSendStream, end-to-end,
full stack, and video_loopback.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2500943002
Cr-Commit-Position: refs/heads/master@{#15087}
The class VideoEncoderSoftwareFallbackWrapper is an implementation
detail of webrtc/media/engine/webrtcvideoengine2.cc and should not be
directly under webrtc/video_encoder.h. The main purpose is to improve
the dependency graph in WebRTC so that VideoEncoderSoftwareFallbackWrapper
can depend on cricket::VideoCodec.
The test for VideoEncoderSoftwareFallbackWrapper is also moved from
webrtc/video/video_encoder_unittest.cc to
webrtc/media/engine/videoencodersoftwarefallbackwrapper_unittest.cc.
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2484863009
Cr-Commit-Position: refs/heads/master@{#15085}
Before this change, the configuration logic in FlexfecReceiveStream
tried to make unsupported configurations work, e.g., by dropping the
protection of some media streams when multiple media streams were
protected by a single FlexFEC stream. This CL makes the configuration logic
return more errors on such unsupported configurations.
This harmonizes the logic with the new configuration logic in
VideoSendStream, for the FlexfecSender.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2499963002
Cr-Commit-Position: refs/heads/master@{#15083}
FlexfecSender is owned and configured by VideoSendStream.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2501503003
Cr-Commit-Position: refs/heads/master@{#15082}
This is undefined behavior, according to specification.
BUG=chromium:661133
Review-Url: https://codereview.webrtc.org/2500953003
Cr-Commit-Position: refs/heads/master@{#15078}
Also extract all iOS sources into a static library configuration
so it's easier to include them in the test target as well.
Also, fix a wrong test that was undiscovered because the
tests were not running
BUG=webrtc:6707
Review-Url: https://codereview.webrtc.org/2502623002
Cr-Commit-Position: refs/heads/master@{#15076}
In DxgiOutputDuplicator, we need to convert between a monitor based coordinate
and a entire screen based coordinate. i.e. Copying an updated area from a
monitor (an output in DirectX API) to the entire screen frame (DesktopFrame).
But DxgiOutputDuplicator always assumes the coordinate is based on screen frame.
So we only need to convert a rectange in updated_region to monitor based
coordinate when copying data from texture_. But in last_frame_, the data are
always based on screen coordinate.
So fixes are both required in line 167 and line 180. In the previous one, we do
not need to convert the DesktopRect, which is already screen based, into screen
based coordinate. In the late one, we do not need to convert the DesktopRect at
all. So after these two changes, DxgiOutputDuplicator::TargetRect() function can
be removed.
Flickers of DirectX capturer can happen on any devices, but a virtual machine
can easily reproduce it. While on a regular high performance machine, it's
harder, but not totally impossible, to reproduce the issue.
BUG=314516
Review-Url: https://codereview.webrtc.org/2495143002
Cr-Commit-Position: refs/heads/master@{#15075}
- Functionality now implemented in AudioReceiveStream and Call.
- Added some missing function to MockChannelProxy.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2461523002
Cr-Commit-Position: refs/heads/master@{#15072}
Previously when BitrateControllerImpl::OnDelayBasedBweResult() is
called as result of a probe it was calling
bandwidth_estimation_.SetSendBitrate(), but not
UpdateDelayBasedEstimate(). As result SendSideBandwidthEstimation was
effectively ignoring probe results as it kept the old
delay_based_bitrate_bps_ value, which caps the resulting bitrate.
BUG=webrtc:6332,webrtc:6710
Review-Url: https://codereview.webrtc.org/2481383002
Cr-Commit-Position: refs/heads/master@{#15071}
This can happen in rare and strange cases.
Also taking the opportunity to replace all asserts with DCHECKs in
that file.
BUG=chromium:659225
Review-Url: https://codereview.webrtc.org/2499013002
Cr-Commit-Position: refs/heads/master@{#15070}
