This will ensure that the estimated likelihood starts at a low value and prevents initial spikes.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2503843004
Cr-Commit-Position: refs/heads/master@{#15131}
We support multiple payload types, and one which matches the audio codec the closest, is picked (or the one with lowest clock rate, if no perfect match is found).
The exact clock rate is then ignored and DTMF packets are time stamped with the rate of the current audio codec. This is exactly the way the code has worked up to this point, but until now we have been under the impression that we were in fact sending 8k DTMF.
In other words, this is an improvement over the current situation, since we will most likely find a payload type which matches the codec clock rate.
This CL also does a little cleaning of the DTMFQueue and RTPSenderAudio classes.
BUG=webrtc:2795
Review-Url: https://codereview.webrtc.org/2392883002
Cr-Commit-Position: refs/heads/master@{#15129}
Parse the estimation parameters from the field trial string.
BUG=webrtc:6690
Review-Url: https://codereview.webrtc.org/2489323002
Cr-Commit-Position: refs/heads/master@{#15126}
To be able to smooth the bandwidth estimation according to the probing interval.
BUG=webrtc:6443
Review-Url: https://codereview.webrtc.org/2380883003
Cr-Commit-Position: refs/heads/master@{#15123}
The red acronym is already in use in the context of audio coding, so it is better to avoid reusing it here because it could be confusing.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2505993002
Cr-Commit-Position: refs/heads/master@{#15121}
This CL wires everything up and enables actual setting of the max bitrate encoding parameter
on the video RTP sender.
The following changes were made
* Add maxbitrate property to the settings model and settings store. Make sure to store and
read the maxbitrate from storage (to persist between app launches and make testing easier)
* Fix setup of encoding parameters for the rtp sender as previous timing was not right.
* Fix header of RTCRtpSender to expose needed parameter
BUG=webrtc:6654
Review-Url: https://codereview.webrtc.org/2492693003
Cr-Commit-Position: refs/heads/master@{#15120}
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}
