This CL adds these classes but does not change any functonality or interface
yet. This is in preparation for future CLs. To be used for this:
https://codereview.webrtc.org/2000163002/
RTCCertificateGenerator is meant to replace DtlsIdentityStoreInterface and
implementations. In order to continue to support mocking and to help with the
transition, RTCCertificateGenerator gets an interface that it implements (just
like the store has both interface and impl).
PeerConnectionFactoryInterface::CreatePeerConnection will take an
RTCCertificateGeneratorInterface instead of DtlsIdentityStoreInterface. As to
not break Chromium, both versions of CreatePeerConnection need to exist for a
transition period. This will be done by wrapping a store into a generator
wrapper - RTCCertificateGeneratorStoreWrapper.
BUG=webrtc:5707, webrtc:5708
R=hta@webrtc.org, tommi@chromium.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2001103002 .
Cr-Commit-Position: refs/heads/master@{#12879}
This is needed as there are targets such as newlib_pnacl/remoting_client_plugin_newlib.pexe that depend on rtc_base_approved but don't need TaskQueue. We could implement support for TaskQueue in nacl using ppapi types, but it looks like there isn't a need for it. Libevent isn't supported for nacl either, so I'm introducing a layer on top of rtc_base_approved for TaskQueue. It's conceivable that this target will morph into a target that holds other threading primitives such as platform_thread and possibly socket related operations, which is also an area that we currently #ifdef out for nacl in a few places.
Functional change: Removes the "is_nacl" check.
R=phoglund@webrtc.org
Review-Url: https://codereview.webrtc.org/2001913002
Cr-Commit-Position: refs/heads/master@{#12878}
This is the minumum allowed size, and will allow STUN pings to be smaller.
The unit tests on the the Gturn are also modified. A username with length of 16 bytes will be generated for Gturn only.
Review-Url: https://codereview.webrtc.org/1848083002
Cr-Commit-Position: refs/heads/master@{#12876}
Reason for revert:
Reverting temporarily. Need to fix tests downstream that pass invalid arguments.
Original issue's description:
> Adding a some checks and switching out a few assert for RTC_[D]CHECK.
> These changes are around use of AudioFrame.data_ to help us catch issues earlier since assert() is left out in release builds, including builds with DCHECK enabled. I've also added a few full-on CHECKs to avoid reading past buffer boundaries or continuing on in a failed state.
>
> BUG=chromium:613482
> NOTRY=true
> (using notry due to offline android_arm64_rel bot)
>
> Committed: https://crrev.com/d36df89d40bde3c62ee5cbff841933e50b3c007b
> Cr-Commit-Position: refs/heads/master@{#12870}
TBR=henrik.lundin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:613482
Review-Url: https://codereview.webrtc.org/2006243002
Cr-Commit-Position: refs/heads/master@{#12874}
Consider follow up and use actual bucket count when storing samples.
BUG=
Review-Url: https://codereview.webrtc.org/2008483002
Cr-Commit-Position: refs/heads/master@{#12872}
There were a series of changes in the calculation of echo metrics. There changes made the existing unittests lose, e.g., EXPECT_EQ become EXPECT_NEAR. It is good time to protect the echo calculation more strictly.
The change is not simply generating a new reference file and change EXPECT_NEAR to EXPECT_EQ. It strengthens the test as well. Main changes are
1. the old test only sample a metric at the end of processing, while the new test takes metrics during the call with a certain time interval. This gives a much stronger protection.
2. added protection of a newly added metric, called divergent_filter_fraction.
3. as said, use EXPECT_EQ (actually ASSERT_EQ) instead of EXPECT_NEAR as much as possible, even for float point values. This may be too restrictive. But it can be good to be restrictive at the beginning.
BUG=
Review-Url: https://codereview.webrtc.org/1969403003
Cr-Commit-Position: refs/heads/master@{#12871}
These changes are around use of AudioFrame.data_ to help us catch issues earlier since assert() is left out in release builds, including builds with DCHECK enabled. I've also added a few full-on CHECKs to avoid reading past buffer boundaries or continuing on in a failed state.
BUG=chromium:613482
NOTRY=true
(using notry due to offline android_arm64_rel bot)
Review-Url: https://codereview.webrtc.org/2007563002
Cr-Commit-Position: refs/heads/master@{#12870}
I looked around and couldn't find any use of these dependencies.
NOTRY=true
(setting NOTRY since merge_libs.gyp isn't actually referenced by any gyp file, it's only used downstream)
Review-Url: https://codereview.webrtc.org/2007883002
Cr-Commit-Position: refs/heads/master@{#12868}
Reason for revert:
Seems like this CL cause
DtlsTransportChannelTest.TestReceiveClientHelloBeforeRemoteFingerprint
DtlsTransportChannelTest.TestReceiveClientHelloBeforeWritable
to consistently fail on Win DrMemory Full and for
DtlsTransportChannelTest.TestReceiveClientHelloBeforeRemoteFingerprint
DtlsTransportChannelTest.TestReceiveClientHelloBeforeWritable
to consistently fail on Linux Memcheck
Original issue's description:
> Change initial DTLS retransmission timer from 1 second to 50ms.
>
> This will help ensure a timely DTLS handshake when there's packet
> loss. It will likely result in spurious retransmissions (since the
> RTT is usually > 50ms), but since exponential backoff is still used,
> there will at most be ~4 extra retransmissions. For a time-sensitive
> application like WebRTC this seems like a reasonable tradeoff.
>
> R=juberti@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
> Cr-Commit-Position: refs/heads/master@{#12853}
TBR=pthatcher@webrtc.org,juberti@webrtc.org,juberti@chromium.org,deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2002403002
Cr-Commit-Position: refs/heads/master@{#12864}
For simplicity, this CL removes the need for Design Support Library.
UI is slightly changed for this to be possible. Floating Action Button
for adding favorite is removed and instead there's a button next to the
TextView.
Review-Url: https://codereview.webrtc.org/2003983002
Cr-Commit-Position: refs/heads/master@{#12861}
This CL makes the loop stop when all frames have been delivered and
start again when a new frame is inserted.
BUG=webrtc:5680
Review-Url: https://codereview.webrtc.org/2000103002
Cr-Commit-Position: refs/heads/master@{#12860}
Check for dropped frames by instead checking the
frame_buffer pointer directly.
Also add RTC_DCHECK to verify that a webrtc::VideoFrame never
has video_frame_buffer_ set to nullptr (except by the default
constructor).
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1995343002
Cr-Commit-Position: refs/heads/master@{#12859}
Some build tools downstream breaks since find on Linux
doesn't support the -E flag.
Shell commands also shouldn't be executed as part of GYP unless there's
no other way around the problem.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2008693002
Cr-Commit-Position: refs/heads/master@{#12858}
According to JSEP, the candidate filter does not affect pooled
candidates because they can be filtered once they're ready to be
surfaced to the application.
So, pooled port allocator sessions will use a filter of CF_ALL, with a
new filter applied when the session is taken by a P2PTransportChannel.
When the filter is applied:
* Some candidates may no longer be returned by ReadyCandidates()
* Some candidates may no longer have a "related address" (for privacy)
* Some ports may no longer be returned by ReadyPorts()
To simplify this, the candidate filtering logic is now moved up from
the Ports to the BasicPortAllocator, with some helper methods to perform
the filtering and stripping out of data.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1998813002 .
Cr-Commit-Position: refs/heads/master@{#12856}
The STUN timeout is 9500ms, and the tests are waiting for 10000ms.
The 500ms margin of error is not enough for some bots (such as UBSan).
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2001093003 .
Cr-Commit-Position: refs/heads/master@{#12854}
This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.
R=juberti@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1981463002 .
Cr-Commit-Position: refs/heads/master@{#12853}
When local candidates are removed, signal to RTCPeerConnection
and eventually send to the remote client.
When a candidate-removal message is received, notify the native PeerConnection.
BUG=
R=tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/1972483002 .
Cr-Commit-Position: refs/heads/master@{#12852}
This helps a lot on Android devices where the user threads can be scheduled with low priority when the app is in the background, causing spurious significantly delayed before a packet can be read from the socket. With this patch the timestamp is taken by the kernel when the packet actually arrives.
R=juberti@chromium.orgTBR=juberti@webrtc.org
BUG=webrtc:5773
Review URL: https://codereview.webrtc.org/1944683002 .
Cr-Commit-Position: refs/heads/master@{#12850}
Drop any pending texture frame when SurfaceTextureHelper.startListening()
is called because the frame might be from the previous
startListening()/stopListening() capture session. This typically happens
when switching between the front/back camera, and an old frame will get
incorrect rotation and mirroring because of the front/back camera
mismatch.
Dropping the frame in SurfaceTextureHelper also removes the need for
the |dropNextFrame| logic in VideoCapturerAndroid.
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/2002963002 .
Cr-Commit-Position: refs/heads/master@{#12849}
During a period (e.g. 2 seconds), different metrics can be computed, e.g.:
- average of samples
- percentage/permille of samples
- units per second
Each periodic metric can be either:
- reported to an observer each period
- aggregated during the call (e.g. min, max, average)
BUG=webrtc:5283
Review-Url: https://codereview.webrtc.org/1640053003
Cr-Commit-Position: refs/heads/master@{#12847}
Of course, functions called WebRtcSpl_AddSatW32 and WebRtcSpl_SubSatW32 are supposed to handle overflow gracefully, and they probably did. But since the overflow handling depended on undefined behavior, a sufficiently smart optimizing compiler would have realized that it could just ignore the possibility of overflow and omit all the overflow handling code, leaving only the unadorned addition or subtraction.
Also, the new implementations, unlike the old ones, result in branch-free code (tested with clang 3.9 with -O2).
BUG=chromium:601728
Review-Url: https://codereview.webrtc.org/2002523002
Cr-Commit-Position: refs/heads/master@{#12846}
I've settled on replacing x << n with x * (1 << n); this gets rid of
the "left shift of negative value" warning, but will still trigger
undefined behavior if the multiplication overflows. It also still
looks like a left shift, which is good for the readability of the
fixed-point code.
(The compiler is smart enough to recognize that the
multiplication+shift is just a shift, for both variable and constant
shift amounts, so the generated code should not change.)
BUG=chromium:603491
Review-Url: https://codereview.webrtc.org/1989803002
Cr-Commit-Position: refs/heads/master@{#12845}
We're now supposed to accept incoming frames from any thread.
BUG=webrtc:5902
Review-Url: https://codereview.webrtc.org/1987663002
Cr-Commit-Position: refs/heads/master@{#12844}
bwe_test_logging.cc is supposed to be conditionally built in gyp builds
but, due to a path error in the sources! expressions it was always
compiled.
Meanwhile, compilation of bwe_test_logging.cc was never set up for gn
builds.
This fixes both of these problems.
BUG=604060
Review-Url: https://codereview.webrtc.org/1990373002
Cr-Commit-Position: refs/heads/master@{#12842}
if the network monitor detects it after the native code does.
Also set the network cost for ethernet, wifi, unknown, cellular network type to be 0, 10, 50, 900,
so that unknown networks will have lower precedence than known networks with low cost (like Wifi) but higher precedence than known networks with high cost.
And third, infer network type based on limited name matching in Android if there is no network monitor or network monitor did not find the type.
BUG=webrtc:5890
R=pthatcher@chromium.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1976683003 .
Cr-Commit-Position: refs/heads/master@{#12833}
Reason for revert:
Downstream code has been updated.
Original issue's description:
> Revert of Android: Make base interface for camera1 and camera2 (patchset #1 id:1 of https://codereview.webrtc.org/1994893002/ )
>
> Reason for revert:
> Still breaks downstream import.
>
> Original issue's description:
> > Reland of Android: Make base interface for camera1 and camera2 (patchset #1 id:1 of https://codereview.webrtc.org/1979583002/ )
> >
> > Reason for revert:
> > Downstream code has been updated.
> >
> > Original issue's description:
> > > Revert of Android: Make base interface for camera1 and camera2 (patchset #3 id:80001 of https://codereview.webrtc.org/1895483002/ )
> > >
> > > Reason for revert:
> > > Breaks downstream import.
> > >
> > > Original issue's description:
> > > > Android: Make base interface for camera1 and camera2
> > > >
> > > > This CL adds a new interface CameraVideoCapturer that extends VideoCapturer with a switchCamera() function. It also moves moves CameraEventsHandler, CameraStatistics, and CameraSwitchHandler from VideoCapturerAndroid to this new interface. The purpose is to prepare for a camera2 implementation that will use the same interfaces and helper class.
> > > >
> > > > BUG=webrtc:5519
> > > >
> > > > Committed: https://crrev.com/6bdacaddfb18edef1f0cdd778209f6b05a8f9210
> > > > Cr-Commit-Position: refs/heads/master@{#12723}
> > >
> > > TBR=perkj@webrtc.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=webrtc:5519
> > >
> > > Committed: https://crrev.com/181b5ffdf036427d92929667d9d43bbcff560435
> > > Cr-Commit-Position: refs/heads/master@{#12727}
> >
> > TBR=perkj@webrtc.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=webrtc:5519
> >
> > Committed: https://crrev.com/d269b023bfe1c321798fe9c8dbd631a562914fe1
> > Cr-Commit-Position: refs/heads/master@{#12807}
>
> TBR=perkj@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5519
>
> Committed: https://crrev.com/bd76607abb712f98c01709f240f147e4bd49df6d
> Cr-Commit-Position: refs/heads/master@{#12809}
TBR=perkj@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5519
Review URL: https://codereview.webrtc.org/1999053002 .
Cr-Commit-Position: refs/heads/master@{#12830}
Updated tests to use the default implementation and removed the test implementation (webrtc/test/histograms.h).
BUG=
Review-Url: https://codereview.webrtc.org/1915523002
Cr-Commit-Position: refs/heads/master@{#12829}
When this class was created, we inadvertently set the default to 64
kbit/s for both cases, failing to preserve the previous behavior. This
patch restores the old behavior.
From what I've been able to dig up, this problem did not affect Opus
encoders created internally in the Audio Coding Module. Those have
always used the bitrate from the supplied CodecInst.
Review-Url: https://codereview.webrtc.org/1942193002
Cr-Commit-Position: refs/heads/master@{#12827}
LooperExecutorTest now uses Robolectric instead of being instrumentation
test. This allows the test to be run faster and easier.
Review-Url: https://codereview.webrtc.org/1989813002
Cr-Commit-Position: refs/heads/master@{#12825}
ThreadUtils.ThreadChecker in WebRTC does the same thing. No point in
having a duplicate implementation.
Review-Url: https://codereview.webrtc.org/1992813007
Cr-Commit-Position: refs/heads/master@{#12824}
LooperExecutor is only truly needed in WebSocketChannelClient because of
WebSocketClient from autobanh requiring thread to have a looper. So
LooperExecutor was left there but replaced everywhere else with built-in
singleThreadExecutor/singleThreadScheduledExecutor.
Motivation behind this change is that built-in class behaves better
under testing environment and doesn't require hacky
RobolectricLooperExecutor.
Review-Url: https://codereview.webrtc.org/1992213002
Cr-Commit-Position: refs/heads/master@{#12823}
