I keep having to re-write these whenever I'm debugging.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2936533003
Cr-Commit-Position: refs/heads/master@{#18586}
Change plotting of detector state from offset and gamma to T and threshold.
BUG=None
Review-Url: https://codereview.webrtc.org/2933243003
Cr-Commit-Position: refs/heads/master@{#18585}
A balance of framerate reduction and resolution down-scaling is used on degrades.
BUG=webrtc:7607
Review-Url: https://codereview.webrtc.org/2887303003
Cr-Commit-Position: refs/heads/master@{#18583}
This CL adds the flag "PORTALLOCATOR_ENABLE_ANY_ADDRESS_PORTS", which will
force the creation of ports not bound to any specific network interface.
These are normally only used when network enumeration fails or is disabled,
but in some circumstances (such as the one the test case adds), they're the
only thing that works.
This will result in extra ports being gathered, which is why it's only enabled
behind a flag for now. In the future, we could probably introduce more
sophisticated "pruning" logic that would lessen the impact of the extra ports
when they're redundant, and make the flag the default.
Some other minor changes that were required to make this use case work:
* Allow a TCPPort to be used for outgoing connections even if it tries and
fails to create a server socket.
* Allow Bind to fail if being called before Connect, and the IP is an "any"
address (0.0.0.0 or ::), since this bind would have been mostly pointless
anyway.
* Prevent P2PTransprotChannel from keeping a "backup" candidate pair using
an "any address" network; we only want this for actual networks.
BUG=webrtc:7798
Review-Url: https://codereview.webrtc.org/2936553003
Cr-Commit-Position: refs/heads/master@{#18578}
PeerConnection::SetBitrate calls PeerConnectionFactory::worker_thread
from multiple threads, so it was triggering the DCHECK. However, the
worker thread never changes after construction, so worker_thread should
be safe to call from multiple threads.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2923953004
Cr-Commit-Position: refs/heads/master@{#18576}
I have updated downstream projects and now it is safe to remove this
header.
BUG=webrtc:7647
NOTRY=True
Review-Url: https://codereview.webrtc.org/2935933002
Cr-Commit-Position: refs/heads/master@{#18561}
In the case of H264 we can't know which packet that is the fist packet of a
frame. In order to avoid creating incomplete frames we keep track of which
packets that we haven't received, and if there is a gap in the packet sequence
number leading up to this frame then a frame wont be created.
BUG=chromium:716558
Review-Url: https://codereview.webrtc.org/2926083002
Cr-Commit-Position: refs/heads/master@{#18559}
Track UIApplication applicationState changes from a C++ class. Uses
NSNotificationCenter to access changes on the main thread and exposes
a local variable that can be checked from any thread.
This fixes a runtime warning on iOS 11 beta.
My Objective-C++ is a little rusty so please check if this follows
the conventions for C++ code in the project. It also changes the
interface exposed by RTCUIApplication.h, not sure if that has impact
on any public APIs that needs to be documented somewhere?
Bug: webrtc:7773
Change-Id: I9c8ba090ef9f28d812114026a906cef742192c39
Reviewed-on: https://chromium-review.googlesource.com/527442
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Kári Tristan Helgason <kthelgason@webrtc.org>
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18558}
This reverts commit b008b45f1e609556a04c1aabb4e8ed6a894265af.
Reason for revert: Breaks external clients.
Original change's description:
> Update webrtc/sdk/objc to new VideoFrameBuffer interface
>
> More thorough refactoring work is planned for RTCVideoFrame (see webrtc:7785), and this CL just unblocks removing the old interface from webrtc::VideoFrameBuffer.
>
> Bug: webrtc:7632,webrtc:7785
> Change-Id: I351536c5ca454c2acd8944bbc2ebb1d1439dc50c
> Reviewed-on: https://chromium-review.googlesource.com/530231
> Reviewed-by: Anders Carlsson <andersc@webrtc.org>
> Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#18553}
TBR=magjed@webrtc.org,andersc@webrtc.org
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:7632,webrtc:7785
Change-Id: Ib5c6fcb939175c67c3ac7b3df7cea0f7c2bb0af0
Reviewed-on: https://chromium-review.googlesource.com/533013
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18557}
This fixes a bug where the generated license for the framework was missing all third party dependencies.
Bug: None
Change-Id: I81331f7f4d32e3302ce6ce0430272904820ce6d6
Reviewed-on: https://chromium-review.googlesource.com/530689
Commit-Queue: Kári Tristan Helgason <kthelgason@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@chromium.org>
Reviewed-by: Daniela Jovanoska Petrenko <denicija@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18556}
More thorough refactoring work is planned for RTCVideoFrame (see webrtc:7785), and this CL just unblocks removing the old interface from webrtc::VideoFrameBuffer.
Bug: webrtc:7632,webrtc:7785
Change-Id: I351536c5ca454c2acd8944bbc2ebb1d1439dc50c
Reviewed-on: https://chromium-review.googlesource.com/530231
Reviewed-by: Anders Carlsson <andersc@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18553}
All of the buffer size returned by Windows Core Audio APIs are in unit
of audio frames (which is sample times number of channels), while
WebRTC's AudioDeviceBuffer RequestPlayoutData method takes in samples
per channel (equivalent to frames per channel) but returns number of
audio samples in all the channels. This CL makes sure that we compare
playout block size in frames with frames and size in samples with
samples, which should fix the excessive logging issues and audio quality
problems due to the mismatch when comparing.
BUG=webrtc:7797
Review-Url: https://codereview.webrtc.org/2933953003
Cr-Commit-Position: refs/heads/master@{#18546}
Since this is a test for a fake network, it's only natural that it uses
a fake clock as well. This makes the tests much faster, less flaky, and
lets them be moved out of "webrtc_nonparallel_tests", since they no
longer have a dependency on any "real" thing (sockets, or time) and
can be run in parallel as easily as any other tests.
As part of this CL, added the fake clock as an argument to
VirtualSocketServer's and TestClient's constructors, since these classes
have methods that wait synchronously for something to occur, and if the
test is using a fake clock, they need to advance it in order to make
progress.
Lastly, added a DCHECK in Thread::ProcessMessages. If called with a
nonzero time while a fake clock is used, it will get stuck in an
infinite loop; a DCHECK is easier to notice than an infinite loop.
BUG=webrtc:7727, webrtc:2409
Review-Url: https://codereview.webrtc.org/2927413002
Cr-Commit-Position: refs/heads/master@{#18544}
const int16_t* data() const;
int16_t* mutable_data();
- data() returns a zeroed static buffer on muted frames (to avoid unnecessary zeroing of the member buffer) and directly returns AudioFrame::data_ on unmuted frames.
- mutable_data(), lazily zeroes AudioFrame::data_ if the frame is currently muted, sets muted=false, and returns AudioFrame::data_.
These accessors serve to "force" callers to be aware of the mute state field, i.e. lazy zeroing is not the primary motivation.
This change only optimizes handling of muted frames where it is somewhat trivial to do so. Other improvements requiring more significant structural changes will come later.
BUG=webrtc:7343
TBR=henrika
Review-Url: https://codereview.webrtc.org/2750783004
Cr-Commit-Position: refs/heads/master@{#18543}
Specifically, just like SafeMin() and SafeMax() it handles all
combinations of integer and all
combinations of floating-point arguments by picking a
result type that is guaranteed to be able to hold the result.
This CL also replaces a bunch of std::min + std:max call pairs with
calls to SafeClamp()---the ones that could easily be found by grep
because "min" and "max" were on the same line. :-)
BUG=webrtc:7459
Review-Url: https://codereview.webrtc.org/2808513003
Cr-Commit-Position: refs/heads/master@{#18542}
This allows to protect ssrc_to_last_received_extended_high_seq_num_ member and
make calls to OnReceivedRtcpReceiverReport thread-safe without introducing new critical section.
Bug: webrtc:7735
Change-Id: Iee23bb780d07b0f906f1f8eeddde2b74cc0a2b89
Reviewed-on: https://chromium-review.googlesource.com/518130
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18540}
