The LOGGING define is only used in a single location in our whole codebase:
$ git gs "f LOGGING"
webrtc/base/physicalsocketserver.cc:1584:#if LOGGING
$ git gs "defined(LOGGING"
(no hits)
The above commands also give no hits in Chromium's code base.
BUG=webrtc:6412
NOTRY=True
Review-Url: https://codereview.webrtc.org/2442743002
Cr-Commit-Position: refs/heads/master@{#14799}
It turns out that that audio network adaptor can always be created with knowledge of receiver frame length range. There is no need to keep some infrastructure that is used for runtime setting of receiver frame length ranges.
BUG=webrtc:6303
Review-Url: https://codereview.webrtc.org/2429503002
Cr-Commit-Position: refs/heads/master@{#14748}
The main reason for doing this is to allow refcounted objects to accept rvalue references in ctor and be able to std::move ctor rvalue arguments.
Also, refcounted.h is now generated using pump.py instead of manually creating each ctor version.
BUG= none
Review-Url: https://codereview.webrtc.org/2425683003
Cr-Commit-Position: refs/heads/master@{#14687}
Currently,
https://build.chromium.org/p/chromium.fyi/builders/CrWinAsan%28dll%29/builds/...
is broken because of
Writing """\
clang_use_chrome_plugins = false
is_asan = true
is_clang = true
is_component_build = true
is_debug = false
llvm_force_head_revision = true
symbol_level = 2
target_cpu = "x86"
v8_enable_verify_heap = true
""" to C:\b\c\b\CrWinAsan_dll_\src\out\Release\args.gn.
C:\b\c\b\CrWinAsan_dll_\src\buildtools\win\gn.exe gen //out/Release --check
--runtime-deps-list-file=C:\b\c\b\CrWinAsan_dll_\src\out\Release\runtime_deps
-> returned 1
ERROR at //third_party/webrtc/base/BUILD.gn:276:21: Undefined identifier in string expansion.
data += [ "$clang_base_path/lib/clang/$clang_version/lib/windows/clang_rt.asan_dynamic-i386.dll" ]
^--------------
"clang_base_path" is not currently in scope.
See //content/test/BUILD.gn:307:7: which caused the file to be included.
"//third_party/webrtc/base:rtc_base",
^-----------------
NOTRY=True
NOPRESUBMIT=True
R=kjellander@webrtc.org, thakis@chromium.org
BUG=chromium:497757
TBR=kjellander
Review-Url: https://codereview.webrtc.org/2422223002
Cr-Commit-Position: refs/heads/master@{#14653}
Gestalt has been deprecated since macOS 10.8, and it's always been overkill for
finding the macOS version anyways. uname works fine.
BUG=webrtc:6027
Review-Url: https://codereview.webrtc.org/2391633004
Cr-Commit-Position: refs/heads/master@{#14589}
Some runtime dependencies on MSVC were missing and had to be added to rtc_base_approved.
BUG=chromium:497757
NOTRY=True
Review-Url: https://codereview.webrtc.org/2389133002
Cr-Commit-Position: refs/heads/master@{#14562}
Reason for revert:
This change broke a downstream application.
Original issue's description:
> Delete transformadapter.cc and transformadapter.h.
>
> BUG=webrtc:6424
>
> Committed: https://crrev.com/2c3c3e27321e4b616bd1222857b2882befc485e3
> Cr-Commit-Position: refs/heads/master@{#14541}
TBR=perkj@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2400443003
Cr-Commit-Position: refs/heads/master@{#14543}
The replacement methods had already been added to applefilesystem.mm, they just
weren't being used on macOS.
BUG=webrtc:6028
Review-Url: https://codereview.webrtc.org/2395593002
Cr-Commit-Position: refs/heads/master@{#14535}
These tests were checking the behavior of thread synchronization
primitives using nothing but carefully timed sleeps. This was very
unreliable and prone to flakes.
This CL replaces the sleeps with waiting on synchronization events.
There is still the need to wait for timeouts when testing for negative
outcomes, but it's greatly reduced. I've run these tests for thousands
of iterations on MSan without a single failure.
BUG=webrtc:5824
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2393023002 .
Cr-Commit-Position: refs/heads/master@{#14534}
Reason for revert:
This CL breaks some downstream dependencies (contact me for more info).
Original issue's description:
> Delete unused code httprequest, httpclient, and socketpool.
>
> BUG=webrtc:6424
>
> Committed: https://crrev.com/4a255be3790a040cae2f6182ed70b7dd38c6839e
> Cr-Commit-Position: refs/heads/master@{#14514}
TBR=perkj@webrtc.org,pthatcher@webrtc.org,nisse@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2397673002
Cr-Commit-Position: refs/heads/master@{#14518}
The test was heavily dependent on wall clock timing, so it ended up
being disabled in some build configurations. This CL switches it to use
a fake clock instead.
BUG=webrtc:5947
Review-Url: https://codereview.webrtc.org/2392613003
Cr-Commit-Position: refs/heads/master@{#14507}
The former is always defined (by webrtc/base/checks.h) to either 0 or
1, whereas the latter isn't necessarily defined.
NOTRY=true
BUG=webrtc:6451
Review-Url: https://codereview.webrtc.org/2384693002
Cr-Commit-Position: refs/heads/master@{#14474}
The implementation is borrowed from Chromium.
Also change use of raw pointers in VideoSendStreamImpl to use WeakPtr<>
BUG= webrtc:6289
Review-Url: https://codereview.webrtc.org/2367853002
Cr-Commit-Position: refs/heads/master@{#14468}
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).
If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).
This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.
BUG=webrtc:6347
R=deadbeef@webrtc.org, honghaiz@webrtc.org, perkj@webrtc.org
Review URL: https://codereview.webrtc.org/2370383002 .
Cr-Commit-Position: refs/heads/master@{#14440}
