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}
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}
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}
Every message will now be traced with the location from which it was
posted, including function name, file and line number.
This CL also writes a normal LOG message when the dispatch took more
than a certain amount of time (currently 50ms).
This logging should help us identify messages that are taking
longer than expected to be dispatched.
R=pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2019423006 .
Cr-Commit-Position: refs/heads/master@{#13104}
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}
We're now ready https://codereview.webrtc.org/1984503002/ downstream,
so make sure we can enable libevent but still choose which libevent
implementation to use. This follows the common pattern where an enable_
flag controls whether we should use the feature at all, whereas build_
controls if we should use the dependency from our DEPS file or
something else.
NOTRY=True
Review-Url: https://codereview.webrtc.org/1980003002
Cr-Commit-Position: refs/heads/master@{#12772}
New task queueing primitive for async tasks: TaskQueue.
TaskQueue is a new way to asynchronously execute tasks sequentially
in a thread safe manner with minimal locking. The implementation
uses OS supported APIs to do this that are compatible with async IO
notifications from things like sockets and files.
This class is a part of rtc_base_approved, so can be used by both
the webrtc and libjingle parts of the WebRTC library. Moving forward,
we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
which means that tasks might execute on different threads depending on
what's the most efficient thing to do.
TBR=perkj@webrtc.org,phoglund@webrtc.org
Review-Url: https://codereview.webrtc.org/1984503002
Cr-Commit-Position: refs/heads/master@{#12749}
Reason for revert:
sigh. Have to revert again as there seems to have have been some change made for pnacl and CrOS.
Original issue's description:
> Reland of New task queueing primitive for async tasks: TaskQueue. (patchset #1 id:1 of https://codereview.webrtc.org/1935483002/ )
>
> New task queueing primitive for async tasks: TaskQueue.
> TaskQueue is a new way to asynchronously execute tasks sequentially
> in a thread safe manner with minimal locking. The implementation
> uses OS supported APIs to do this that are compatible with async IO
> notifications from things like sockets and files.
>
> This class is a part of rtc_base_approved, so can be used by both
> the webrtc and libjingle parts of the WebRTC library. Moving forward,
> we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
>
> NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
> run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
> which means that tasks might execute on different threads depending on
> what's the most efficient thing to do.
>
> TBR=perkj@webrtc.org
>
> Committed: https://crrev.com/65d1f2aba216d077c6d22488f03e56984aef1c68
> Cr-Commit-Position: refs/heads/master@{#12737}
TBR=perkj@webrtc.org,phoglund@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/1981573002
Cr-Commit-Position: refs/heads/master@{#12738}
New task queueing primitive for async tasks: TaskQueue.
TaskQueue is a new way to asynchronously execute tasks sequentially
in a thread safe manner with minimal locking. The implementation
uses OS supported APIs to do this that are compatible with async IO
notifications from things like sockets and files.
This class is a part of rtc_base_approved, so can be used by both
the webrtc and libjingle parts of the WebRTC library. Moving forward,
we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
which means that tasks might execute on different threads depending on
what's the most efficient thing to do.
TBR=perkj@webrtc.org
Review-Url: https://codereview.webrtc.org/1927133004
Cr-Commit-Position: refs/heads/master@{#12737}
Reason for revert:
Breaks user code. Said code needs to stop using scoped_ptr!
Original issue's description:
> Remove webrtc/base/scoped_ptr.h
>
> BUG=webrtc:5520
>
> NOTRY=True
>
> Committed: https://crrev.com/65fc62e9dd8a8716db625aaef76ab92f542ecc5a
> Cr-Commit-Position: refs/heads/master@{#12684}
TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5520
Review-Url: https://codereview.webrtc.org/1965063003
Cr-Commit-Position: refs/heads/master@{#12686}
And redefine rtc::Buffer as
using Buffer = BufferT<uint8_t>;
(In the long run, I'd like to remove the type alias and rename the
template to just rtc::Buffer, but that requires all current users of
Buffer to start saying Buffer<uint8_t> instead, and since Buffer is
used in the API, we can't do that in one step.)
The immediate reason for the new template is that we'd like to use
BufferT<int16_t> in the AudioDecoder interface.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/1929903002
Cr-Commit-Position: refs/heads/master@{#12564}
Reason for revert:
Reverting this temporarily while I figure out the issues with the Chrome on android GN debug build.
Original issue's description:
> New task queueing primitive for async tasks: TaskQueue.
> TaskQueue is a new way to asynchronously execute tasks sequentially
> in a thread safe manner with minimal locking. The implementation
> uses OS supported APIs to do this that are compatible with async IO
> notifications from things like sockets and files.
>
> This class is a part of rtc_base_approved, so can be used by both
> the webrtc and libjingle parts of the WebRTC library. Moving forward,
> we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
>
> NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
> run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
> which means that tasks might execute on different threads depending on
> what's the most efficient thing to do.
TBR=perkj@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/1935483002
Cr-Commit-Position: refs/heads/master@{#12562}
TaskQueue is a new way to asynchronously execute tasks sequentially
in a thread safe manner with minimal locking. The implementation
uses OS supported APIs to do this that are compatible with async IO
notifications from things like sockets and files.
This class is a part of rtc_base_approved, so can be used by both
the webrtc and libjingle parts of the WebRTC library. Moving forward,
we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
which means that tasks might execute on different threads depending on
what's the most efficient thing to do.
Review-Url: https://codereview.webrtc.org/1919733002
Cr-Commit-Position: refs/heads/master@{#12561}
Moves logic of default SocketServer from MessageQueue to SocketServer
Review-Url: https://codereview.webrtc.org/1891293002
Cr-Commit-Position: refs/heads/master@{#12541}
- Places most ObjC code into webrtc/sdk/objc instead.
- New gyp targets to build, strip and export symbols for dylib.
- Removes old script used to generate dylib.
BUG=
Review URL: https://codereview.webrtc.org/1903663002
Cr-Commit-Position: refs/heads/master@{#12524}
This is more a correction than a change since bind.h was incorrectly not
a part of rtc_base when building with Chromium while still being used
(since it's a header file only). The only dependencies that bind.h has,
are in rtc_base_approved, so there's no need to restrict usage of it to
rtc_base users only.
NOTRY=true
TBR=perkj
NO_DEPENDENCY_CHECKS=true
Review URL: https://codereview.webrtc.org/1911403002 .
Cr-Commit-Position: refs/heads/master@{#12474}
When building as part of Chromium, webrtc/base/logging.h is overridden
by webrtc_overrides/webrtc/base/logging.h that uses Chromium logging
macros.
The implementation of webrtc/base/objc/RTCFileLogger.{h,mm} however has
dependency on the webrtc implementation of logging as it define a class
that inherits from rtc::LogSink. Since the class does not exists when
the overrides are used, the file fails compilation.
Fixes the compilation for iOS as part of Chromium by not compiling the
file webrtc/base/objc/RTCFileLogger.{h,mm} in that configuration.
BUG=459705
Review URL: https://codereview.webrtc.org/1898283002
Cr-Commit-Position: refs/heads/master@{#12438}
This is a new way of generating RTCCertificate objects that is meant
to replace DtlsIdentityStoreInterface and all of its implementations
(clean up work).
It is similar to the identity store in that it generates on the worker
thread and does callback on the signaling thread, but:
- It does not generate identities in the background that you did not
ask for (preemptive generation made more sense before certificates
were parameterized, not so much anymore, and ECDSA which will be most
common takes like <=2 ms to generate).
- As such this code is less complicated than the store's code.
- The API is different, it takes Optional<uint64_t> expires and it
returns RTCCertificates, not SSLIdentities.
- It supports a blocking version of GenerateCertificate that can be
called from any thread, necessary for Chrome which can generate
certificates before the signaling/worker threads have been
initialized as WebRTC-threads (Chrome can invoke this version on
the worker thread outside of WebRTC).
This CL does not remove the identity store, only adds the alternative.
Follow-up CLs will start using it, the store will be removed once it
is no longer used anywhere.
BUG=webrtc:5707, webrtc:5708
R=hta@webrtc.org, torbjorng@webrtc.org
Review URL: https://codereview.webrtc.org/1883813002 .
Cr-Commit-Position: refs/heads/master@{#12381}
- First audio RTP packet sent / received
- First RTP packet of the first video frame sent / received
- Last RTP packet of the first video frame sent / received
These timestamps should make it easier to measure how fast the call
becomes established from the user's perspective.
Review URL: https://codereview.webrtc.org/1765443002
Cr-Commit-Position: refs/heads/master@{#12287}
* Remove all source exclusions since they make the file very hard to
read and heavily increases the risk for mistakes.
* Don't compile the openssl* sources if use_openssl==0.
* Move platform specific sources into conditional includes to make it
easier to verify a 1:1 mapping with BUILD.gn (since GN doesn't support
automatic detection of platform specific sources based on filenames).
* Add missing sources for the GN build.
* Reorder some blocks to make GYP vs GN mapping match.
BUG=webrtc:4256
R=perkj@webrtc.org, torbjorng@webrtc.org
Review URL: https://codereview.webrtc.org/1859803002 .
Cr-Commit-Position: refs/heads/master@{#12235}
The other buffer classes as well as all other dependencies are in rtc_base_approved, so I think this is a better place for it. Additionally I found that code in Chromium that already depends on the other buffer classes but now depends on the CopyOnWriteBuffer class, needed to have their build files updated and they previously depended on the buffer classes in rtc_base_approved.
TBR=jbauch@webrtc.org
Review URL: https://codereview.webrtc.org/1820643002
Cr-Commit-Position: refs/heads/master@{#12059}
When the iOS application is not in the foreground, the hardware encoder and
decoder become invalidated. There doesn't seem to be a way to query their state
so we don't know they're invalid until we get an error code after an
encode/decode request. To solve the issue, we just don't encode/decode when the
app is not active, and reinitialize the encoder/decoder when the app is active
again.
Also fixes a leak in the decoder.
BUG=webrtc:4081
Review URL: https://codereview.webrtc.org/1732953003
Cr-Commit-Position: refs/heads/master@{#11916}
This copies the contents (unittest excluded) of base/numerics in
chromium to base/numerics in webrtc. Files added:
- safe_conversions.h
- safe_conversions_impl.h
- safe_math.h
- safe_math_impl.h
A really old version of safe_conversions[_impl].h previously existed in
base/, this has been deleted and sources using it have been updated
to include the new base/numerics/safe_converions.h.
This CL also adds a DEPS file to webrtc/base.
NOPRESUBMIT=True
BUG=webrtc:5548, webrtc:5623
Review URL: https://codereview.webrtc.org/1753293002
Cr-Commit-Position: refs/heads/master@{#11907}
Things done/implemented in this CL:
- An interface that can send Nack (VCMNackSender).
- An interface that can request KeyFrames (VCMKeyFrameRequestSender).
- The nack module (NackModule).
- A set of convenience functions for modular numbers (mod_ops.h).
BUG=webrtc:5514
Review URL: https://codereview.webrtc.org/1715673002
Cr-Commit-Position: refs/heads/master@{#11882}
This CL introduces a new class CopyOnWriteBuffer that holds data in a
refcounted Buffer which is shared between copied CopyOnWriteBuffer to avoid
unnecessary allocations / memory copies.
BUG=webrtc:5155
Review URL: https://codereview.webrtc.org/1697743003
Cr-Commit-Position: refs/heads/master@{#11767}
