Reason for revert:
Chromium build issues have been resolved.
Original issue's description:
> Revert of Remove all reference to carbon api (patchset #2 id:20001 of https://codereview.webrtc.org/2299633002/ )
>
> Reason for revert:
> Breaks chromium build
>
> Original issue's description:
> > Remove all reference to carbon api
> >
> > BUG=webrtc:6282
> >
> > Committed: https://crrev.com/dbd8b6bec4143c940b2f2ca8cd85c25d17327964
> > Cr-Commit-Position: refs/heads/master@{#14080}
>
> TBR=magjed@webrtc.org,mflodman@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6282
>
> Committed: https://crrev.com/b096aa7fd375a980daab3a986596548ca5de2a1c
> Cr-Commit-Position: refs/heads/master@{#14081}
TBR=magjed@webrtc.org,mflodman@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6282
Review-Url: https://codereview.webrtc.org/2321493002
Cr-Commit-Position: refs/heads/master@{#14125}
Reason for revert:
Breaks chromium build
Original issue's description:
> Remove all reference to carbon api
>
> BUG=webrtc:6282
>
> Committed: https://crrev.com/dbd8b6bec4143c940b2f2ca8cd85c25d17327964
> Cr-Commit-Position: refs/heads/master@{#14080}
TBR=magjed@webrtc.org,mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6282
Review-Url: https://codereview.webrtc.org/2316563002
Cr-Commit-Position: refs/heads/master@{#14081}
In addition to setting or appending from another Buffer, which was
already possible, this allows for e.g. std::vector and rtc::ArrayView
arguments.
Review-Url: https://codereview.webrtc.org/2293983002
Cr-Commit-Position: refs/heads/master@{#14073}
The sample uses are from when I debugged bug 617124. The change in neteq_network_stats_unittest.cc is a fix for a minor unrelated bug found by the try bots when I tried to land this CL (a test was passing uninitialized packet data to NetEq).
BUG=chromium:617124
Review-Url: https://codereview.webrtc.org/2293893002
Cr-Commit-Position: refs/heads/master@{#14034}
This is step 2 of the plan below.
The modified plan
1. First land unmodified task_queue.h into webrtc_override in Chrome
2. Modify build files in the webrtc repo to include the task_queue.h and task_queue.cc from webrtc_overrides. This will breaks webrtc Chrome FYI.
3. Combine a roll of webrtc to Chrome and a the cl in https://codereview.chromium.org/2293913003/ into one cl.
The combined cl will roll in build files from 2 and add task_queue.cc in webrtc_overrides and build task_queue_unittest.cc as part of content_unittests to test task_queue.cc in webrtc_overrides.
4... Start using task queues in webrtc........
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2289203002
Cr-Commit-Position: refs/heads/master@{#13983}
Reason for revert:
Upstream fixes in place, should be OK now.
Original issue's description:
> Revert of Refactor NACK bitrate allocation (patchset #16 id:300001 of https://codereview.webrtc.org/2061423003/ )
>
> 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: 5fc59e810b
>
> TBR=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=
>
> Committed: https://crrev.com/e5dd44101eca485f5ad12e5f7ce6f6b0d204116b
> Cr-Commit-Position: refs/heads/master@{#13417}
TBR=tommi@webrtc.org,danilchap@webrtc.org,stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.webrtc.org/2146013002
Cr-Commit-Position: refs/heads/master@{#13465}
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:
It keeps breaking upstream.
Original issue's description:
> Reland Issue 2061423003: Refactor NACK bitrate allocation
>
> This is a reland of https://codereview.webrtc.org/2061423003/
> Which was reverted in https://codereview.webrtc.org/2131913003/
>
> The reason for the revert was that some upstream code used
> RtpSender::SetTargetBitrate(). I've added that back as a no-op until we
> it's been brought up to date.
>
> TBR=tommi@webrtc.org
>
> Committed: 05ce4ae31fTBR=tommi@webrtc.org,sprang@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/2130423002
Cr-Commit-Position: refs/heads/master@{#13419}
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}
Reason for revert:
Creating template CL for reland
Original issue's description:
> Revert of Cleanup webrtc/base/base.gyp (patchset #2 id:80001 of https://codereview.webrtc.org/1859803002/ )
>
> Reason for revert:
> For some odd reason this breaks chromium.webrtc.fyi bots:
> ../../third_party/webrtc_overrides/webrtc/base/win32socketinit.cc:13:2: error: "Only compile this on Windows"
> #error "Only compile this on Windows"
> ^
> 1 error generated.
>
> https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/11515/steps/compile/logs/stdio
> https://build.chromium.org/p/chromium.webrtc.fyi/builders/Linux%20Builder/builds/4650/steps/compile/logs/stdio
>
> Original issue's description:
> > Cleanup webrtc/base/base.gyp
> >
> > * 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
> >
> > Committed: https://crrev.com/47f33cb28ffb0fa0f053ae0aa0086e11f85bf444
> > Cr-Commit-Position: refs/heads/master@{#12235}
>
> TBR=perkj@webrtc.org,torbjorng@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:4256
> NOTRY=True
>
> Committed: https://crrev.com/c8587ad92d394bfb60498df1209a3beb9017e001
> Cr-Commit-Position: refs/heads/master@{#12237}
TBR=perkj@webrtc.org,torbjorng@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4256
Review URL: https://codereview.webrtc.org/1857163003
Cr-Commit-Position: refs/heads/master@{#12242}
* 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}