This it to avoid requiring targets that include header files that in turn use SequenceTaskedChecker, to also have to define the macros needed by TaskQueue.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2145393003
Cr-Commit-Position: refs/heads/master@{#13482}
It causes an asan initialization-order-fiasco in trying to read the
names of other globally constructed data:
==21449==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7f6f297bc5e8 at pc 0x7f6f26b332a7 bp 0x7ffd479f8cb0 sp 0x7ffd479f8ca8
READ of size 8 at 0x7f6f297bc5e8 thread T0
#0 0x7f6f26b332a6 in name
webrtc/base/flags.h:83:38
#1 0x7f6f26b332a6 in Lookup
webrtc/base/flags.cc:133
#2 0x7f6f26b332a6 in rtc::FlagList::Register(rtc::Flag*)
webrtc/base/flags.cc:260
#3 0x7f6f2529972b in __cxx_global_var_init.1
BUG=
Review-Url: https://codereview.webrtc.org/2110963004
Cr-Commit-Position: refs/heads/master@{#13479}
This updates how we initialize timer events to be the same way as we initialize non-timer events.
BUG=
Review-Url: https://codereview.webrtc.org/2147973002
Cr-Commit-Position: refs/heads/master@{#13468}
event_set() has been deprecated and doesn't allow passing the main loop to be passed to initialize the event. event_assign() is the method to call in Event2 when available. However, we still need to be compatible with Chromium's version of libevent, so there's an #ifdef check in the meantime.
BUG=
Review-Url: https://codereview.webrtc.org/2141193002
Cr-Commit-Position: refs/heads/master@{#13454}
SequencedTaskChecker is a helper class used to help verify that some methods
of a class are called on the same task queue or thread. A
SequencedTaskChecker is bound to a a task queue if the object is
created on a task queue, or a thread otherwise.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2125113003
Cr-Commit-Position: refs/heads/master@{#13452}
The issue was that if the main entry routine of the thread would get called before the first APC, the thread would hang on a GetMessage() call and the APC sent to initialize the thread, would never run.
BUG=
Review-Url: https://codereview.webrtc.org/2139723003
Cr-Commit-Position: refs/heads/master@{#13438}
Reason for revert:
Breaks upstream code.
Original issue's description:
> Refactor NACK bitrate allocation
>
> Nack bitrate allocation should not be done on a per-rtp-module basis,
> but rather shared bitrate pool per call. This CL moves allocation to the
> pacer and cleans up a bunch if bitrate stats handling.
>
> BUG=
> R=danilchap@webrtc.org, stefan@webrtc.org, tommi@webrtc.org
>
> Committed: 5fc59e810bTBR=tommi@webrtc.org,danilchap@webrtc.org,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2131913003
Cr-Commit-Position: refs/heads/master@{#13417}
ASSERT(!crit_.CurrentThreadIsOwner()) was racy due to use of a rtc::IsThreadRefEqual which cannot compare the thread handlers without a lock unless one is already sure it is the thread owning the crit.
Review-Url: https://codereview.webrtc.org/2131503002
Cr-Commit-Position: refs/heads/master@{#13411}
The function uses a deprecated function and is unused, so delete it.
BUG=6027
NOTRY=true
Review-Url: https://codereview.webrtc.org/2114013002
Cr-Commit-Position: refs/heads/master@{#13400}
Everything calls GetOSVersionName() instead, so no need to expose that.
Since it uses deprecated functions, this will make it easier to rewrite
it in a future change.
BUG=webrtc:6027
NOTRY=true
Review-Url: https://codereview.webrtc.org/2117823002
Cr-Commit-Position: refs/heads/master@{#13399}
There was a fast path in PreprocessToAddData that would just use the
input timestamps if the input format was equal to the required format of
the encoder. This works well as long as the codec never changes. If we
are first doing resampling (specifically upsampling) and then change to
a codec that does not require resampling, we'll need to stick to
whatever input timestamp we left off at, rather than silently accepting
whatever we're sent.
BUG=622435
Review-Url: https://codereview.webrtc.org/2119393002
Cr-Commit-Position: refs/heads/master@{#13398}
we will periodically check if any network does not have any connection on it and if yes, attempt to re-gather on those networks.
BUG=
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2025573002 .
Cr-Commit-Position: refs/heads/master@{#13367}
Permits CHECKing/DCHECKing that methods are being accessed in a
thread-safe manner, even if they are not used by one single thread
(thread pools such as VideoToolbox OK).
BUG=
R=danilchap@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2097403002 .
Cr-Commit-Position: refs/heads/master@{#13358}
The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).
The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
- PeerConnectionFactory.startInternalTracingCapture().
I've separated these two methods to make it more clear which of the
parameters controls which system.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2110853003
Cr-Commit-Position: refs/heads/master@{#13334}
If the AutoDetectProxy timed out resolving one address, it was
attempting to use the same resolver to resolve the next address,
which would always result in an assertion. This happened recently
a couple times on the Windows DrMemory bot because of its slowness.
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2104203002 .
Cr-Commit-Position: refs/heads/master@{#13326}
The fake clock has a few advantages:
1. It lets use verify that operations take the expected number of
round trips.
2. It makes the tests faster by letting us remove the equivalent
of "Sleep(500)" all over the tests.
3. It makes the tests less flaky, because sometimes sleeping for
500ms or waiting for 1s is not enough.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2097793003 .
Cr-Commit-Position: refs/heads/master@{#13304}
Reason for revert:
Didn't intend to land yet. Chromium CL still needed.
Original issue's description:
> Add virtual Initialize methods to PortAllocator and NetworkManager.
>
> This will allow PeerConnection to handle hopping to the right thread
> and doing thread-specific initialization for the PortAllocator.
> This eliminates a required thread-hop for whatever is passing the
> PortAllocator into CreatePeerConnection.
>
> BUG=617648
> R=pthatcher@webrtc.org, skvlad@webrtc.org
>
> Committed: https://crrev.com/a6bdb0990a659ff9e7c4374f5033a6bcc4fbfb21
> Cr-Commit-Position: refs/heads/master@{#13283}
TBR=pthatcher@webrtc.org,skvlad@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=617648
Review-Url: https://codereview.webrtc.org/2092023004
Cr-Commit-Position: refs/heads/master@{#13284}
This will allow PeerConnection to handle hopping to the right thread
and doing thread-specific initialization for the PortAllocator.
This eliminates a required thread-hop for whatever is passing the
PortAllocator into CreatePeerConnection.
BUG=617648
R=pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2097653002 .
Cr-Commit-Position: refs/heads/master@{#13283}
Reason for revert:
It turns out this revert was not necessary because the connection-state mapping for turn-turn connections was not done in connection.
Original issue's description:
> Revert of Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://… (patchset #5 id:120001 of https://codereview.webrtc.org/2041593002/ )
>
> Reason for revert:
> ReadyToSendMedia did not consider the new presumed_writable state.
>
> Original issue's description:
> > Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://codereview.webrtc.org/2000063003/ )"
> >
> > This reverts commit 72d41aa6da94dacb8a8464d1abd4ca7d1afffc65.
> >
> > New change made:
> > Do not reset the BWE when the new network route is not ready to send media.
> >
> > BUG=
> > R=pthatcher@webrtc.org, stefan@webrtc.org
> >
TBR=pthatcher@webrtc.org,stefan@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2094863003
Cr-Commit-Position: refs/heads/master@{#13282}
If the specification for the speech encoder hasn't changed, we should
reuse it instead of recreating it. Otherwise, we lose its state. (This
problem was originally discovered because AudioEncoderOpus instances
would forget that they were supposed to be using DTX.)
BUG=webrtc:6020, chromium:622647
Review-Url: https://codereview.webrtc.org/2089183002
Cr-Commit-Position: refs/heads/master@{#13273}
Reason for revert:
The Webrtc waterfall indicates that this revert is not necessary.
Original issue's description:
> Revert of Do not delete a connection in the turn port with permission error or refresh error. (patchset #6 id:260001 of https://codereview.webrtc.org/2068263003/ )
>
> Reason for revert:
> It broke webrtc builds.
>
> Original issue's description:
> > Do not delete a connection in the turn port with permission error, refresh error, or binding error.
> >
> > Even if those error happened, the connection may still be able to receive packets for a while.
> > If we delete the connections, all packets arriving will be dropped.
> >
> > BUG=webrtc:6007
> > R=deadbeef@webrtc.org, pthatcher@webrtc.org
> >
> > Committed: https://crrev.com/3d77deb29c15bfb8f794ef3413837a0ec0f0c131
> > Cr-Commit-Position: refs/heads/master@{#13262}
>
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> TBR=pthatcher@webrtc.org,deadbeef@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:6007
>
> Committed: https://crrev.com/3159ffae6b1d5cba2ad972bd3d8074ac85f2c7f9
> Cr-Commit-Position: refs/heads/master@{#13265}
TBR=pthatcher@webrtc.org,deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6007
Review-Url: https://codereview.webrtc.org/2090073003
Cr-Commit-Position: refs/heads/master@{#13266}
Reason for revert:
It broke webrtc builds.
Original issue's description:
> Do not delete a connection in the turn port with permission error, refresh error, or binding error.
>
> Even if those error happened, the connection may still be able to receive packets for a while.
> If we delete the connections, all packets arriving will be dropped.
>
> BUG=webrtc:6007
> R=deadbeef@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/3d77deb29c15bfb8f794ef3413837a0ec0f0c131
> Cr-Commit-Position: refs/heads/master@{#13262}
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=pthatcher@webrtc.org,deadbeef@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6007
Review-Url: https://codereview.webrtc.org/2090833002
Cr-Commit-Position: refs/heads/master@{#13265}
Even if those error happened, the connection may still be able to receive packets for a while.
If we delete the connections, all packets arriving will be dropped.
BUG=webrtc:6007
R=deadbeef@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2068263003 .
Cr-Commit-Position: refs/heads/master@{#13262}
The Camera1 and Camera2 API use different size types. Camera1 uses
android.hardware.Camera.Size while Camera2 uses android.util.Size.
android.util.Size is only available from Lollipop forward so this CL
adds a similar Size class in CaptureFormat.
The purpose of this CL is to have a common size type that can be reused
from both Camera1 and Camera2 helper functions such as
CameraEnumerationAndroid.getClosestSupportedSize().
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2066773002
Cr-Commit-Position: refs/heads/master@{#13181}
An rtc::Buffer is used to write output of RBSP parsing, usually one byte
at a time. It turns out that container will then expand its capacity one
byte at a time, for each byte reallocating the whole buffer and copying
the contents over, turning this into an O(n^2) operation.
Fix is for now only to preallocate the container storage. Longer term, I
think we should mull over if we really need custom containers...
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
BUG=
Review URL: https://codereview.webrtc.org/2073763002 .
Cr-Commit-Position: refs/heads/master@{#13167}
The function GetExecutablePath is a hack with poor portability. Delete
it and its caller GetTestFilePath. The latter was used in
videoframe_unittest.h, where it is replaced by
webrtc::test::ResourcePath.
Delete unused functions declared in base/testutils.h: ReadFile,
GetSiblingDirectory, GetGoogle3Directory, GetTalkDirectory,
CmpHelperFileEq, EXPECT_FILEEQ, ASSERT_FILEEQ.
Delete unused functions declared in media/base/testutils.h:
GetTestFilePath (see above), LoadPlanarYuvTestImage,
DumpPlanarYuvTestImage, ComputePSNR, ComputeSumSquareError.
The functions LoadPlanarYuvTestImage, DumpPlanarYuvTestImage were used
in yuvscaler_unittests.cc and planarfunctions_unittests.cc, under
webrtc/pc. However, these tests are never compiled or run, and appear
not to have been for the last few years, and are therefore deleted
rather than updated. It might make sense to check if libyuv have
comparable tests, and if not, resurrect them as part of libyuv
unittests.
BUG=
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/2058043002 .
Cr-Commit-Position: refs/heads/master@{#13163}
Reason for revert:
Reverting after experiment. What seems to happen is that the thread can't be stopped when PostThreadMessage fails with this error code (or lack thereof).
Original issue's description:
> Attempt to figure out what the issue is on the Win10 FYI build bot in content_browsertests.
> Check for the case when PostThreadMessage returns false but GetLastError returns ERROR_SUCCESS.
>
> TBR=olka
> NOTRY=true
>
> Committed: https://crrev.com/e11041159d6e66fb25c2e045ad1558fc99d2d6cd
> Cr-Commit-Position: refs/heads/master@{#13143}
TBR=olka@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/2067013003
Cr-Commit-Position: refs/heads/master@{#13147}
Check for the case when PostThreadMessage returns false but GetLastError returns ERROR_SUCCESS.
TBR=olka
NOTRY=true
Review-Url: https://codereview.webrtc.org/2063313003
Cr-Commit-Position: refs/heads/master@{#13143}
The error hasn't been noticed since we don't really do
(or support) Mac 32-bit builds.
BUG=webrtc:5949
NOTRY=True
Review-Url: https://codereview.webrtc.org/2065583002
Cr-Commit-Position: refs/heads/master@{#13111}
