The signal was only being hooked up for incoming connections, not
outgoing connections.
As a result, the bandwidth estimator didn't know when packets were sent
and couldn't calculate delays.
BUG=webrtc:7509
Review-Url: https://codereview.webrtc.org/2834083002
Cr-Commit-Position: refs/heads/master@{#17817}
Otherwise, the activeCount will become negative.
BUG=webrtc:7471
Review-Url: https://codereview.webrtc.org/2822233002
Cr-Commit-Position: refs/heads/master@{#17816}
Introduce new small header-only targets in system_wrappers:
:cpu_features_api
:field_trial_api
:metrics_api
to untangle and optimize dependencies but still satisfy GN check.
In webrtc/p2p, previously uncovered header "base/fakecandidatepair.h"
is added to :p2p_test_utils target.
Refactor system_wrappers so 'rtc_p2p' can depend on only
system_wrappers:field_trial_api instead of all of system_wrappers
(which led to a breakage in Chromium that called for the revert of
https://codereview.webrtc.org/2735583002).
BUG=webrtc:6828
NOTRY=True
Review-Url: https://codereview.webrtc.org/2739863002
Cr-Commit-Position: refs/heads/master@{#17812}
Before this CL, we would negotiate:
- No crypto suites for data m= sections.
- A full set for audio m= sections.
- The full set, minus SRTP_AES128_CM_SHA1_32 for video m= sections.
However, this doesn't make sense with BUNDLE, since any DTLS
association could end up being used for any type of media. If
video is "bundled on" the audio transport (which is typical), it
will actually end up using SRTP_AES128_CM_SHA1_32.
So, this CL moves the responsibility of deciding SRTP crypto suites out
of BaseChannel and into DtlsTransport. The only two possibilities are
now "normal set" or "normal set + GCM", if enabled by the PC factory
options.
This fixes an issue (see linked bug) that was occurring when audio/video
were "bundled onto" the data transport. Since the data transport
wasn't negotiating any SRTP crypto suites, none were available to use
for audio/video, so the application would get black video/no audio.
This CL doesn't affect the SDES SRTP crypto suite negotiation;
it only affects the negotiation in the DLTS handshake, through
the use_srtp extension.
BUG=chromium:711243
Review-Url: https://codereview.webrtc.org/2815513012
Cr-Commit-Position: refs/heads/master@{#17810}
When SSRCs aren't signaled, an SSRC of 0 is used internally to mean
"the default receive stream". But this wasn't working with the
implementation of GetRtpReceiveParameters in the audio/video
engines. This was breaking RtpReceiver.GetParameters in this situation,
as well as the new getStats implementation (which relies on
GetParameters).
The new implementation will fail if *no* default receive stream is
configured (meaning no default sink is set), and otherwise will return
a default RtpEncodingParameters (later it will be filled with relevant
SDP parameters as they're implemented).
BUG=webrtc:6971
Review-Url: https://codereview.webrtc.org/2806173002
Cr-Commit-Position: refs/heads/master@{#17803}
This patch fixes the internal AudioCoder output buffer setting to be set
prior it will be used within callback from ACM
BUG=webrtc:7462
Review-Url: https://codereview.webrtc.org/2806933002
Cr-Commit-Position: refs/heads/master@{#17800}
obvious, WindowCapturerWin should not return Result::SUCCESS with an empty
frame.
This issue was original introduced into the code base in change
https://codereview.webrtc.org/1988783003/.
I am also considering whether we should move the
previous_size_ = frame->size();
window_size_map_[window_] = previous_size_;
into the true branch. But since this change needs to be merged into M58 and M59,
I would prefer to keep it as small as possible.
BUG=712615
Review-Url: https://codereview.webrtc.org/2835553002
Cr-Commit-Position: refs/heads/master@{#17799}
Documenting that the observer can safely be destroyed after Close has
been called, because it ensures no more callbacks will be invoked. Just
like in JavaScript land, where no more events will be fired after
"close" is called.
This is already covered by unit tests.
BUG=webrtc:7491
NOTRY=True
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2834543005
Cr-Commit-Position: refs/heads/master@{#17798}
The key change of this CL is to merge ScreenCapturerWinDirectx::frames_ and
contexts_ into a new DxgiFrame class. So consumers of DxgiDuplicateController
does not need to maintain two objects. DxgiDuplicateController::Duplicate*()
functions are also updated to accept DxgiFrame parameter instead of
SharedDesktopFrame + Context. The advantages of this change are,
1. Once the screen resolution changes or an existing monitor has been removed,
DxgiFrame can automatically reset the frame without needing to return a capture
failure.
2. Remove public APIs of DxgiDuplicatorController. Some public APIs are not
needed anymore, i.e. consumers of DxgiDuplicatorController do not need to take
care about these internal states anymore. It also helps to remove several lock
acquiements.
3. Reduce the complexity of ScreenCapturerWinDirectx.
But the disadvantage is, instead of a boolean value,
DxgiDuplicateController::Duplicate*() now return an enumeration. Clients need to
use the enumeration to decide whether the error can be recovered or not.
This change also removes a duplicating logic in ScreenCapturerWinDirectx. i.e.
ResolutionChangeDetector, DxgiDuplicateController now takes care of the screen
resolution changes.
I have verified the scenarios with and without SharedMemoryFactory, also the
Desktop capture API example. So far no regression is detected.
BUG=704205
Review-Url: https://codereview.webrtc.org/2788863006
Cr-Commit-Position: refs/heads/master@{#17795}
And changed the minimum increase rate in |aimd_rate_control| to prevent the system from overusing on short twcc report send interval.
BUG=webrtc:6514
Review-Url: https://codereview.webrtc.org/2407143002
Cr-Commit-Position: refs/heads/master@{#17794}
in favor of GetPacketStatusCount/GetReceivedPackets
BUG=webrtc:5565
Review-Url: https://codereview.webrtc.org/2822153002
Cr-Commit-Position: refs/heads/master@{#17792}
Follow-up CL on https://codereview.webrtc.org/2788883002/ where I add a new
test which has to be enabled manually (will not run by default on bots).
Measures loopback latency and reports the min, max and average values for
a full duplex audio session.
The latency is measured like so:
- Insert impulses periodically on the output side.
- Detect the impulses on the input side.
- Measure the time difference between the transmit time and receive time.
- Store time differences in a vector and calculate min, max and average.
This test needs the '--gtest_also_run_disabled_tests' flag to run and also
some sort of audio feedback loop. E.g. a headset where the mic is placed
close to the speaker to ensure highest possible echo. It is also recommended
to run the test at highest possible output volume.
How to run:
./out/Debug/modules_unittests --gtest_filter=AudioDeviceMeasureLoopbackLatency --gtest_also_run_disabled_tests
Example output (on Linux machine):
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AudioDeviceTest
[ RUN ] AudioDeviceTest.DISABLED_MeasureLoopbackLatency
[..........]
[..........] [min, max, avg]=[59, 67, 64] ms
[ OK ] AudioDeviceTest.DISABLED_MeasureLoopbackLatency (10034 ms)
[----------] 1 test from AudioDeviceTest (10034 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (10036 ms total)
[ PASSED ] 1 test.
BUG=webrtc:7273
Review-Url: https://codereview.webrtc.org/2826073002
Cr-Commit-Position: refs/heads/master@{#17791}
There's some code that resets the ICE role on an ICE restart (behavior
that's specified in ICE, but removed from ICEbis). And it wasn't taking
into account that the remote endpoint may be an ICE lite endpoint, in
which case the WebRTC endpoint's role should always be "controlling".
BUG=chromium:710760
Review-Url: https://codereview.webrtc.org/2812173003
Cr-Commit-Position: refs/heads/master@{#17779}
Instead of using the time on the first callback to Call::OnSentPacket, use the time when the first packet is sent from the pacer (to make sure this packet corresponds to an audio/video RTP packet).
BUG=webrtc:6244
Review-Url: https://codereview.webrtc.org/2825333002
Cr-Commit-Position: refs/heads/master@{#17777}
