This field shouldn't have been in the class in the first place.
Bug: webrtc:7760
Change-Id: If3c1d24f18a643249da1ed072bdfe06a37a7da12
Reviewed-on: https://chromium-review.googlesource.com/535539
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18593}
Imprecisions in floating point representation caused noise in the
graphs. The integer division is in fact exact.
BUG= webrtc:7467
Review-Url: https://codereview.webrtc.org/2933053002
Cr-Commit-Position: refs/heads/master@{#18592}
This CL adds the capability to analyze and plot how NetEq behaves in
response to a network trace.
BUG=webrtc:7467
Review-Url: https://codereview.webrtc.org/2876423002
Cr-Commit-Position: refs/heads/master@{#18590}
LastDecoderError was only used in tests. LastError was only used in
conjunction with RemovePayloadType, and always to distinguish between
"decoder not found" and "other error". In AcmReceiver, "decoder not
found" was not treated as an error.
With this change, calling NetEq::RemovePayloadType with a payload type
that is not registered is no longer considered to be an error. This
allows to rewrite the code in AcmReceiver, such that it no longer has
to call LastError.
The internal member variables NetEqImpl::error_code_ and
NetEqImpl::decoder_error_code_ are removed, since they were no longer
read.
Bug: none
Change-Id: Ibfe97265954a2870c3caea4a34aac958351d7ff1
Reviewed-on: https://chromium-review.googlesource.com/535533
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18588}
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}
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}
This is to make it possible to override the rtc_task_queue target only.
BUG=none
Review-Url: https://codereview.webrtc.org/2931273002
Cr-Commit-Position: refs/heads/master@{#18534}
For devices with multiple cameras, all supported resolutions from both
the front-facing and back cameras are listed.
Bug: webrtc:7783
Change-Id: I228eda28ea48181c86d344413dda9f3a71b0864f
Reviewed-on: https://chromium-review.googlesource.com/529045
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Daniela Jovanoska Petrenko <denicija@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18533}
