The APM limiter is a component for keeping the audio from clipping by smoothly reducing the amplitude of the audio samples. It can be rather expensive because of band-splitting & merging. Also, experiments indicate that it is of questionable benefit (adding several sources of human speech almost never cause clipping).
To optionally disable the limiter, this CL does some refactoring on the (quite large) AudioMixerImpl. Functionality related to actual addition of frames and handling AudioFrame meta-data (sample_rate, num_channels, samples_per_channel, time_stamp, elapsed_time_ms) is broken out in a new sub-component called FrameCombiner.
The FrameCombiner is initialized with a 'use_limiter' flag. To create a mixer without using the APM limiter
Inside of FrameCombiner, the meta-data handling and the audio sample addition are kept divided from each other.
This also fixes a few minor GN issues so that warnings do not have to be suppressed.
BUG=webrtc:7167
Review-Url: https://codereview.webrtc.org/2692333002
Cr-Commit-Position: refs/heads/master@{#16742}
RTCVideoFrame is an ObjectiveC version of webrtc::VideoFrame, but it
currently contains some extra logic beyond that. We want RTCVideoFrame
to be as simple as possible, i.e. just a container with no extra state,
so we can use it as input to RTCVideoSource without complicating the
interface for consumers.
BUG=webrtc:7177
NOTRY=True
Review-Url: https://codereview.webrtc.org/2695203004
Cr-Commit-Position: refs/heads/master@{#16740}
This happens if a lot of FEC is allocated when the stream becomes suspended. The required bitrate to unsuspend can then be too high so that the padding bitrate we are allowed to generate is not enough.
This CL also switches the tests from using ISAC to OPUS as RampUpTest.UpDownUpAudioVideoTransportSequenceNumberRtx relies on audio BWE to work (which is only compatible with OPUS). I don't know why it didn't fail before.
BUG=webrtc:7178
Review-Url: https://codereview.webrtc.org/2705603002
Cr-Commit-Position: refs/heads/master@{#16739}
The purpose of this visualization CL is to add the ability to record
video at the source, after encode, and after decode, in the VideoProcessor
tests. These output files can then be replayed and used as a subjective
complement to the objective metric plots given by the existing Python
plotting script.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2700493006
Cr-Commit-Position: refs/heads/master@{#16738}
The video_capture module includes remnants of support for cameras
producing encoded frames. However, this seems to be unused, and is
explicitly not supported by VideoCaptureImpl::IncomingFrame.
BUG=None
Review-Url: https://codereview.webrtc.org/2668693008
Cr-Commit-Position: refs/heads/master@{#16732}
These tests involve interactions with the file system, so to avoid
flakiness they shouldn't be run in parallel.
BUG=webrtc:7195
NOTRY=True
Review-Url: https://codereview.webrtc.org/2710433003
Cr-Commit-Position: refs/heads/master@{#16727}
The partial availability problem aries from the fact that the minimum
supported OSX version is set to 10.9, but AppRTCMobile is using
functions available only in 10.10 and later. The minimum OSX version is
set as a declare_args() in build/config/mac/mac_sdk.gni, which makes it
difficult to override for just the AppRTCMobile target in WebRTC.
Instead, this CL solves the problem for now by removing the usage of the
10.10 function, which is trivial.
Also, the flag:
'extra_substitutions = [ "MACOSX_DEPLOYMENT_TARGET=10.8" ]'
is removed since it has no effect.
BUG=webrtc:4695
Review-Url: https://codereview.webrtc.org/2710493002
Cr-Commit-Position: refs/heads/master@{#16726}
Moves CameraCapturer, CameraSession, Camera1Session and Camera2Session
away from the public API.
BUG=webrtc:7172
Review-Url: https://codereview.webrtc.org/2699713004
Cr-Commit-Position: refs/heads/master@{#16723}
together with related functions and variables
to stress it is used for Tmmbr only.
This is explicitly pure rename CL with no functional changes.
BUG=webrtc:5565
Review-Url: https://codereview.webrtc.org/2707763004
Cr-Commit-Position: refs/heads/master@{#16720}
Rename loss based and delay based bwe updates in proto (and correspondingly in the C++ code).
BUG=webrtc:6423
Review-Url: https://codereview.webrtc.org/2705613002
Cr-Commit-Position: refs/heads/master@{#16719}
gtest can print objects if they have an operator<< or a PrintTo
function in the same namespace as the object's class. Since
std::optional does not seem to have an operator<<, it'd be preferable
not to rely on rtc::Optional being printable through operator<<.
Currently, gtest errors will just dump the raw bytes of
rtc::Optionals, which make them really annoying to work with in tests.
BUG=webrtc:7196
Review-Url: https://codereview.webrtc.org/2704483002
Cr-Commit-Position: refs/heads/master@{#16717}
This CL adds the ability to _create_ HW codecs (Android and iOS) in the
VideoProcessor integration tests. Since the VideoProcessor class is not thread
safe yet, this CL does not add the ability to _use_ HW codecs in the tests. A
follow-up CL is planned that will add this ability.
This CL further adds a separate build target which is used to separate the
"plot" versions of the integration tests from the "correctness" versions. The
former will be run manually on devices, whereas the latter are used on the
trybots/buildbots to find regressions in the SW codecs. The underlying test
is the same, however.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2695653002
Cr-Commit-Position: refs/heads/master@{#16716}
Running video loopback on https://appr.tc/ revealed that it is possible
to use the same SSRC for a local and remote audio or video track. This
caused a DCHECK crash. The constructor of TrackMediaInfoMap is updated
to support this mapping and the unittest is updated (moved and modified
a test from being a death test to being a non-death test).
I've verified that this fixes the bug.
BUG=chromium:693087
Review-Url: https://codereview.webrtc.org/2703783002
Cr-Commit-Position: refs/heads/master@{#16713}
This is step 1 in the following process to move the task runner
abstraction over to Chrome, without gettings link errors on duplicate
symbols.
1. Move files from the rtc_base target to a new target
rtc_task_runner, and let rtc_base publicly depend on it.
2. In Chrome, add an explicit dependency on rtc_task_runner where it
depends on rtc_base.
3. Drop the webrtc dependency rtc_base --> rtc_task_runner.
4. Copy task runner code to Chrome (cl
https://codereview.chromium.org/2694903005/), and drop its
dependency on webrtc's rtc_task_runner target.
5. Delete the rtc_task_runner target and corresponding source files
from webrtc. Mission accomplished!
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2696703009
Cr-Commit-Position: refs/heads/master@{#16710}
This reduces binary size considerably and solves some other problems.
Also rewrote using variadic templates.
Initial patch contributed by andrey.semashev@gmail.com.
BUG=webrtc:2305
Review-Url: https://codereview.webrtc.org/2509733003
Cr-Commit-Position: refs/heads/master@{#16703}
This change adds a flag, use_sctpmap, to DataContentDescription. The deserialization code sets the flag based on the format of the m= line.
There were already unit tests using SDP in the new format, so I just updated them to check use_sctpmap was set as expected.
The change to mediasession copies use_sctpmap from the offered DataContentDescription to the answer.
I haven't figured out how to test this change yet, but wanted to get feedback before continuing.
BUG=chromium:686212
Review-Url: https://codereview.webrtc.org/2690943011
Cr-Commit-Position: refs/heads/master@{#16686}
The AsyncClosures only ever have one thing referencing them, so they
should be using std::unique_ptr to manage ownership. Maybe this code was
written before std::unique_ptr was available.
Originally reverted because it made a change to ScopedMessageData
that wasn't backwards compatible, and applications using the rtc::Thread
infrastructure may be using it.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2689233003
Cr-Commit-Position: refs/heads/master@{#16684}
Reason for revert:
The change to messagequeue.h isn't backwards compatible. Will reland after making it backwards compatible.
Original issue's description:
> Use std::unique_ptr instead of rtc::scoped_refptr in AsyncInvoker.
>
> The AsyncClosures only ever have one thing referencing them, so they
> should be using std::unique_ptr to manage ownership. Maybe this code was
> written before std::unique_ptr was available.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2689233003
> Cr-Commit-Position: refs/heads/master@{#16680}
> Committed: a5a472927bTBR=pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2703613006
Cr-Commit-Position: refs/heads/master@{#16683}
The first unsignalled SSRC creates a default receive channel.
Any unsignalled SSRC changes after that replace the default SSRC.
Add unit tests for changing unsignalled SSRCs.
BUG=webrtc:5208
Review-Url: https://codereview.webrtc.org/2692993009
Cr-Commit-Position: refs/heads/master@{#16682}
The AsyncClosures only ever have one thing referencing them, so they
should be using std::unique_ptr to manage ownership. Maybe this code was
written before std::unique_ptr was available.
BUG=None
Review-Url: https://codereview.webrtc.org/2689233003
Cr-Commit-Position: refs/heads/master@{#16680}
This implementation uses various legacy classes such as EventTimeWrapper,
CriticalSectionWrapper, EventWrapper etc and hasn't been maintained
(or used?) for a long time.
Instead of spending time on testing and updating the class, I think
we should just remove it. For versions of Windows that we support,
following Win7, we use the CoreAudio implementation.
BUG=webrtc:7183
R=solenberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2700983002 .
Cr-Commit-Position: refs/heads/master@{#16678}
FallbackDesktopCapturerWrapper is a DesktopCapturer implementation, which owns
two DesktopCapturer implementations. If the main DesktopCapturer fails, it uses
the secondary capturer. The logic is now used in ScreenCapturerWinMagnifier, and
it can also be shared in ScreenCapturerWinDirectx to fallback to Gdi capturer on
privilege prompt or login screen.
BUG=684937
Review-Url: https://codereview.webrtc.org/2697453002
Cr-Commit-Position: refs/heads/master@{#16677}
This does not fix the myriad of other problems here, but at least
removes the dependency on CONF_VALUE.
BUG=526270
Review-Url: https://codereview.webrtc.org/2705603003
Cr-Commit-Position: refs/heads/master@{#16676}
The url of the ICE server is added to the IceCandiate class.
This can be used to tell which server this candidate was gathered from.
BUG=webrtc:7128
Review-Url: https://codereview.webrtc.org/2690593002
Cr-Commit-Position: refs/heads/master@{#16675}
This is necessary in case the drawer doesn't cover all the pixels.
BUG=None
Review-Url: https://codereview.webrtc.org/2704663002
Cr-Commit-Position: refs/heads/master@{#16671}
and the method RTPSender::GenerateNewSSRC.
It's now mandatory for higher layers to call SetSSRC, RTPSender
no longer allocates any ssrc by default.
BUG=webrtc:4306,webrtc:6887
Review-Url: https://codereview.webrtc.org/2644303002
Cr-Commit-Position: refs/heads/master@{#16670}
This a pre-step for improving perfomance of the RTCPReceiver
- rest of the ReceiveInfo is tmmbr related and
can be handled only when tmmbr is explicitly enabled.
BUG=webrtc:5565
Review-Url: https://codereview.webrtc.org/2681003003
Cr-Commit-Position: refs/heads/master@{#16667}
