This perf tests the echo detector in 3 scenarios: standalone, as part of APM with only the echo detector enabled and as part of a normally configured APM.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2517523003
Cr-Commit-Position: refs/heads/master@{#15224}
RunPlayoutAndRecordingInFullDuplex fails sometimes on Android swarming
bots, presumably because the timing is hardware dependent.
This test ensures that audio starts pumping. The exact performance is
not that important.
R=kjellander@webrtc.org, henrika@webrtc.org
BUG=webrtc:6464
NOTRY=True
Review-Url: https://codereview.webrtc.org/2525943003
Cr-Commit-Position: refs/heads/master@{#15223}
The histogram will log a new value every time the AGC changes level_.
BUG=webrtc:6622
Review-Url: https://codereview.webrtc.org/2525963002
Cr-Commit-Position: refs/heads/master@{#15222}
This change adds RotateDesktopFrame(), RotateRect(), RotateSize(),
ReverseRotate() functions, so an implementation can use these free functions to
rotate and copy pixels from one DesktopFrame to another at the same time.
This is the first part of the change to support rotation in DirectX capturer. In
a coming change, these functions will be used in DxgiOutputDuplicator to do the
rotation and copying.
Background,
DirectX APIs always return unrotated data buffer, so we need to rotate it to
match the user-selected rotation. What worse is except for the data buffer,
other variables return by these APIs are all rotated, e.g. output size, monitor
position. So we will eventually not be able to capture the rotated monitors,
because we cannot set their position and size correctly. Though
DXGI_OUTDUPL_DESC provides a DXGI_MODE_ROTATION enumeration to indicate the
output rotation, it does not provide a simple way to rotate an IDXGIResource,
which is the only thing we can get from duplication APIs. A typical user case
here is to use a matrix to transform the IDXGIResource and render it to a
surface. But since we do not render the IDXGIResource at all, we need to
manually rotate it.
BUG=314516
Review-Url: https://codereview.webrtc.org/2500883004
Cr-Commit-Position: refs/heads/master@{#15205}
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
R=honghaiz@webrtc.org, philipel@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2458863002 .
Committed: https://crrev.com/5c99c76255ee7bface3c742c25fb5617748ac86e
Cr-Original-Commit-Position: refs/heads/master@{#15094}
Cr-Commit-Position: refs/heads/master@{#15204}
Set the |qp_| field in EncodedImage before calling OnEncodedImage.
BUG=webrtc:6541
Review-Url: https://codereview.webrtc.org/2499003002
Cr-Commit-Position: refs/heads/master@{#15199}
the APM parameters to the high-pass filter.
The introduction will be done in three steps:
1) This CL which introduces the new scheme and
changes the code in webrtcvoiceengine.cc to use it.
2) Introduce the scheme into upstream code.
3) Remove the HighPassFilter interface in APM.
BUG=webrtc::6220, webrtc::6296, webrtc::6297, webrtc::6181, webrtc::5298
Review-Url: https://codereview.webrtc.org/2415403002
Cr-Commit-Position: refs/heads/master@{#15197}
This new histogram will log a value every time input clipping is
detected. The value is a boolean, with "true" meaning that the gain
was in fact adjusted in response to the detected clipping, and "false"
meaning that adjustment was not allowed due to kClippedLevelMin.
BUG=webrtc:6622
Review-Url: https://codereview.webrtc.org/2522543006
Cr-Commit-Position: refs/heads/master@{#15196}
This change adds code that lets Opus increase the complexity setting
at low bitrates (only relevant for mobile where the default complexity
is not already maximum). The feature is default off.
Also adding a performance test to make sure the complexity adaptation
has desired effect.
BUG=webrtc:6708
Review-Url: https://codereview.webrtc.org/2503443002
Cr-Commit-Position: refs/heads/master@{#15182}
A recent cl (https://codereview.webrtc.org/2510583002) introduced an
issue where the initial rate allocation (call to VideoBitrateAllocator
and any associated temporal layers) uses framerate = 0 fps. This may
cause issues, including having the rate control in ScreenshareLayers
ramp up too slowly.
This CL make the initial call use VideoCodec.maxFramerate as framerate.
Also expanded unit tests.
BUG=webrtc:6301
Review-Url: https://codereview.webrtc.org/2513383002
Cr-Commit-Position: refs/heads/master@{#15166}
They just decay to pointers anyway, so it's more honest to declare
them as pointers.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2515163002
Cr-Commit-Position: refs/heads/master@{#15165}
ScreenCapturerIntegrationTest is flaky on Windows systems due to some unknown
reason. But it's do easily impacted by the environment, so this change adds more
logging (entire screenshot) to help debugging.
Meanwhile, this change also includes a nice-to-have change in ScreenDrawerWin to
always bring the window to front in each WaitForPendingDraws() function call. I
cannot quite tell whether this change can help to resolve the issue, but it is
worth trying.
BUG=webrtc:6666
Review-Url: https://codereview.webrtc.org/2492723002
Cr-Commit-Position: refs/heads/master@{#15158}
Move the resources to //resources and upload them to Google Storage.
BUG=webrtc:6727
Review-Url: https://codereview.webrtc.org/2508943004
Cr-Commit-Position: refs/heads/master@{#15152}
In the AudioMixerImpl implementation, removing a source never fails
and the return value is always true (see audio_mixer/audio_mixer_impl.cc).
A return value of |false| signaled that removing a source failed for
some reason. We have come to the conclusion that
* we don't know how to handle a return value of |false|
* we can't think of why an alternative implementation would need to
signal failure when removing a stream.
To avoid having a status code that is never read, never acted upon and
probably never set to anything but |true|, we change ::RemoveSource to
not have a return value.
NOTRY=True
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2506173003
Cr-Commit-Position: refs/heads/master@{#15150}
Reason for revert:
Breaks downstream projects:
error: undefined reference to 'rtc::ExpFilter::kValueUndefined'
error: undefined reference to 'rtc::ExpFilter::Apply(float, float)'
error: undefined reference to 'rtc::ExpFilter::Reset(float)'
rror: undefined reference to 'rtc::ExpFilter::UpdateBase(float)'
Original issue's description:
> Move smoothing filter to common audio.
>
> This will make the smoothing filter a basic tool that is going to be used by both voice engine and ANA.
>
> BUG=webrtc:6443
>
> Committed: https://crrev.com/a82395bf7cd15b7396456df06fe952ede8db0c39
> Cr-Commit-Position: refs/heads/master@{#15146}
TBR=minyue@webrtc.org,solenberg@webrtc.org,perkj@webrtc.org,tommi@webrtc.org,michaelt@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6443
Review-Url: https://codereview.webrtc.org/2510373002
Cr-Commit-Position: refs/heads/master@{#15147}
This will make the smoothing filter a basic tool that is going to be used by both voice engine and ANA.
BUG=webrtc:6443
Review-Url: https://codereview.webrtc.org/2484153002
Cr-Commit-Position: refs/heads/master@{#15146}
This is a refactoring change in preparation for enabling AudioMixer
with the goal to have a small CL as possible for passing audio through
the new audio mixer in WebRTC. The dependent CL https://codereview.webrtc.org/2436033002/
enables the mixer.
An object of class AudioState is shared across different webrtc audio
connections. It is created in tests and in
WebRTCVoiceEngine. AudioState is constructed by passing a Config
struct, where one argument is scoped_refptr<AudioMixer>.
Populating this field has now been mandatory. Tests and
WebRTCVoiceEngine create and pass either a AudioMixerImpl.
WebRTCVoiceEngine passes a real AudioMixer, which is
currently unused.
An alternative would have tests pass a mocked audio mixer. We
chose not to do that, because we believe that tests should use
the real thing unless there are reasons against it. Construction
time is not an issue, because the real mixer is relatively
lightweight.
We couldn't find a way to test any mixer-related changes in AudioState
before the mixes is connected. The next dependent CL
https://codereview.webrtc.org/2436033002/ contains unit tests for
mixer usage.
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2469743002
Cr-Commit-Position: refs/heads/master@{#15134}
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}
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}
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}
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}
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}
