Code using the macro change to a plain declaration+init of a local
variable.
Also delete includes of <stdint.h> and <stddef.h> from basictypes.h.
Bug: webrtc:6853
Change-Id: I5ffceb449c1bf8f5badb595d5a343a47b0c6deae
Reviewed-on: https://webrtc-review.googlesource.com/78460
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23377}
Instead of making multiple calls to the std::stringstream << operator,
collect all the arguments and make a single printf-like variadic call
under the hood.
Besides reducing our reliance on iostreams, this makes each RTC_LOG_*
call site smaller; in aggregate, this reduces the size of
libjingle_peerconnection_so.so by 28-32 kB.
A quick benchmark indicates that this change makes log statements
a few percent slower.
Bug: webrtc:8982, webrtc:9185
Change-Id: I3137a4dd8ac510e8d910acccb0c97ce4fffb61c9
Reviewed-on: https://webrtc-review.googlesource.com/75440
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Jonas Olsson <jonasolsson@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23375}
This reverts commit 3409cfa378e75c0c08d900e0848147929249a62b.
Reason for revert: Broke WebRtcBrowserTest.RunsAudioVideoWebRTCCallInTwoTabsH264 on Windows 7/10 bots
Original change's description:
> Start supporting H264 packetization mode 0.
>
> The work was already done to support it, but it wasn't being negotiated
> in SDP.
>
> This means we'll now see 8 H264 payload types instead of 4; one for each
> combination of BP/CBP profiles, packetization modes 0/1, and RTX/non-RTX.
> This could be problematic in the future, since we're starting to run
> out of dynamic payload types (using 25 of 32).
>
> Bug: chromium:600254
> Change-Id: Ief2340db77c796f12980445b547b87e939170fae
> Reviewed-on: https://webrtc-review.googlesource.com/77264
> Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23372}
TBR=deadbeef@webrtc.org,magjed@webrtc.org,sprang@webrtc.org
Change-Id: I2f2a2b4ca20ba883764cd5265911e1453d3df66e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:600254
Reviewed-on: https://webrtc-review.googlesource.com/78398
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23374}
The work was already done to support it, but it wasn't being negotiated
in SDP.
This means we'll now see 8 H264 payload types instead of 4; one for each
combination of BP/CBP profiles, packetization modes 0/1, and RTX/non-RTX.
This could be problematic in the future, since we're starting to run
out of dynamic payload types (using 25 of 32).
Bug: chromium:600254
Change-Id: Ief2340db77c796f12980445b547b87e939170fae
Reviewed-on: https://webrtc-review.googlesource.com/77264
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23372}
This avoid sending more padding than required for the current target
constraints.
Bug: webrt:8415
Change-Id: I3a668990f026414ab78f8406248cde18b81123cc
Reviewed-on: https://webrtc-review.googlesource.com/77763
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23364}
The BBR controller did not properly report updates to congestion
windows. This was due to a check to avoid the overhead of callbacks.
In the current design without callbacks in the controller, the check can
be removed. If helpful for performance, it should live outside of the
controller.
Bug: webrtc:8415
Change-Id: Idf6d6e76fe6d0450841e706019110307e559c11d
Reviewed-on: https://webrtc-review.googlesource.com/78181
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23363}
This prepares for making the BBR implementation more identical to the
implementation in Quic, this is to ensure that results are comparable.
Bug: webrtc:8415
Change-Id: I6b182246c988dd4a95681c063dcaa779088d0e99
Reviewed-on: https://webrtc-review.googlesource.com/76481
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23356}
The Quic BBR implementation uses packet sequence numbers to keep track
of the time slots used for calculation of send receive rates. To avoid
protocol dependence the port were initially written to use send times
instead.
As there are issues with running BBR in WebRTC, it makes sense to
use an identical implementation as in Quic to ensure that there
aren't implementation issues causing bad behavior. This requires
providing sequence numbers.
This prepares for making the BBR implementation more identical to the
implementation in Quic, this is to ensure that results are comparable.
Bug: webrtc:8415
Change-Id: I2cd96bc6ffb88042bb2b91421bfe6cbf7c1ff8ac
Reviewed-on: https://webrtc-review.googlesource.com/76583
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23353}
This CL implements a fix behind a field trial for a NetEq issue. NetEq restarts audio too quickly after a buffer underrun, which can quickly lead to another underrun in some circumstances. The fix changes NetEq's behavior to wait with restarting playback until sufficient audio is buffered.
Bug: webrtc:9289
Change-Id: I5968c9478ce8d84caf77f00b8d0a39156b47fc8d
Reviewed-on: https://webrtc-review.googlesource.com/77423
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23347}
These files are required when implementing tests based on the test fixture,
and should be exposed as part of the test api.
This CL also removes a usage of stringstream and fixes some chromium-style
lint issues.
Bug: webrtc:8982, webrtc:163
Change-Id: I132aea0da79a79587887f21897236fc9802b7574
Reviewed-on: https://webrtc-review.googlesource.com/74586
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23346}
NetEq tapers down the audio produced through loss concealment when the
expansion has been going on for some time. When the audio packets starts
coming in again, there is a ramp-up that happens. This ramp-up could
before this change extend over more than one 10 ms block, which made
keeping track of the scaling factor necessary. With this change, we make
this ramp-up quicker in the rare cases when it lasted more than 10 ms,
so that it always ramps up to 100% within one block. This way, we can
remove the mute_factor_array.
This change breaks bit-exactness, but careful listening could not reveal
an audible difference.
This change is a part of a larger refactoring of NetEq's PLC code.
Bug: webrtc:9180
Change-Id: I4c513ce3ed8d66f9beec2abfb1f0c7ffaac7a21e
Reviewed-on: https://webrtc-review.googlesource.com/77180
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23342}
This CL fixes the rounding of the estimated average call skew. Before it
was rounded down (toward INT_MIN). Now it is rounded to the nearest integer.
This avoids unnecessary fluctuations of the estimated call skew (and
unnecessary resets).
Bug: webrtc:9283,chromium:888042
Change-Id: Id5b3c593f812f5f9fd3dcdafb7e388a6ef1ac153
Reviewed-on: https://webrtc-review.googlesource.com/77684
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23338}
This is a kitchen-sink header, some pieces should be moved to
byteorder.h, the rest likely deleted.
Delete most includes of basictypes.h. In leaf headers,
include stddef.h and stdint.h explicitly where needed.
Bug: webrtc:6853
Change-Id: Ibc809936a8f94d418e4eb650da1e89c1b9142073
Reviewed-on: https://webrtc-review.googlesource.com/77721
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23333}
Instead of checking for an exact bitrate check that the bitrate is between
the min and max values.
Also relax a threshold in a bandwith adaptation test.
Bug: webrtc:9280
Change-Id: I465d785a53759f73242198ee1ccd7da1a26c48b7
Reviewed-on: https://webrtc-review.googlesource.com/78041
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23330}
The ERLE computation was improved by two means:
- The update function was always called and just parts of the internal code reacts to the converged filter flag
- When computing the ERLE, the ratio of energies is now computed using more points and, therefore, a more robust estimation is achieved.
Bug: webrtc:9284
Change-Id: Ie4f871f19cfad1a13741352ddd7b0a27ad6c3fb6
Reviewed-on: https://webrtc-review.googlesource.com/77767
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23329}
The overflow currently does not cause any problems, but it has been
found that it can cause crashes after a refactoring that is coming in
the near future.
Bug: webrtc:9180
Change-Id: Ia2c4e545c062c4f8ad13cbc47b8796c6e8a4e906
Reviewed-on: https://webrtc-review.googlesource.com/77667
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23327}
This is a reland of 79ded653fee7183d5c0d94c5addf570bcfb29c9e
Original change's description:
> Update expected bitrate in Opus tests
>
> Upstream changes to Opus DTX behavior changes the bitrates of Opus. This
> CL re-enables recently disabled unittests and updates the expected bitrates.
>
> Bug: webrtc:9280
> Change-Id: I668a0b6a8b82cbbb70d795db4546cb5469266bf2
> Reviewed-on: https://webrtc-review.googlesource.com/77766
> Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
> Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23306}
TBR=henrik.lundin@webrtc.org
Bug: webrtc:9280
Change-Id: I6bfcd1c5e1d5298543024a0faa6a695026434df3
Reviewed-on: https://webrtc-review.googlesource.com/77980
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23318}
- Limit framerate by dropping frames before encoding.
- The max framerate at screen sharing is set to 5fps.
Bug: webrtc:9261
Change-Id: Icfbbecce33fdce2d746291708db0108e0ba10760
Reviewed-on: https://webrtc-review.googlesource.com/76921
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23316}
- Remove referencing control from encoder wrapper. Use fixed temporal
prediction structure.
- Remove flexible mode from encoder wrapper. It only worked with
referencing control which this CL removes.
- Remove external framerate/bitrate controller. Keep codec's internal
frame dropping enabled at screen sharing.
- Use GetSvcConfig() to configure layering.
Bug: webrtc:9261
Change-Id: I355baa6aab7b98ac5028b3851d1f8ccc82a308e0
Reviewed-on: https://webrtc-review.googlesource.com/76801
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23311}
This CL applies a high pass filter to the delay estimator signals which
improves the adaptation of the matched filters in noisy environments.
This results in faster delay estimation.
Bug: webrtc:9288
Change-Id: I8ffe5442eab7ac2f10a7ba236b08a0f07ec90645
Reviewed-on: https://webrtc-review.googlesource.com/77725
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23308}
This reverts commit 79ded653fee7183d5c0d94c5addf570bcfb29c9e.
Reason for revert: Different repos have different Opus
Original change's description:
> Update expected bitrate in Opus tests
>
> Upstream changes to Opus DTX behavior changes the bitrates of Opus. This
> CL re-enables recently disabled unittests and updates the expected bitrates.
>
> Bug: webrtc:9280
> Change-Id: I668a0b6a8b82cbbb70d795db4546cb5469266bf2
> Reviewed-on: https://webrtc-review.googlesource.com/77766
> Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
> Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23306}
TBR=henrik.lundin@webrtc.org,gustaf@webrtc.org
Change-Id: I3c18db2d6052c4049d836c3e595b00189aebcbc8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9280
Reviewed-on: https://webrtc-review.googlesource.com/77800
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23307}
Upstream changes to Opus DTX behavior changes the bitrates of Opus. This
CL re-enables recently disabled unittests and updates the expected bitrates.
Bug: webrtc:9280
Change-Id: I668a0b6a8b82cbbb70d795db4546cb5469266bf2
Reviewed-on: https://webrtc-review.googlesource.com/77766
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23306}
This CL increases the allowed variations in the API call skew limit in
AEC3.
Bug: webrtc:9283,chromium:888042
Change-Id: Ib5e784c6f3dcf1bf3a2cbfe2b1559953db9227a8
Reviewed-on: https://webrtc-review.googlesource.com/77430
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23305}
This is a reland of 89653d5db46419d2a80898635cb27fed64898db2
Original change's description:
> [desktopCapture] Unify the position info in DIP coordinates on Mac.
>
> On OSX, the logical(DIP) and physical coordinates are used mixingly.
> For example, the captured image has its size in physical pixels(2x) and
> location in logical(DIP) pixels. Same to the cursor position. This
> causes trouble when we check the relative position of image and cursor
> when there are multiple monitors with different DIP setting connected.
>
> This cl proposed a solution to use DIP pixel for any location info,
> i.e. top-left of a frame and cursor position. Also propose a method to
> get the current scale factor of a window across multiple monitors. And
> save the current scale factor in DPI of the capture frame.
> Then we can check relative position of cursor and frame correctly
> in DIP pixel and compose them in physical pixel.
>
> Bug: webrtc:9178
> Change-Id: I3c076aeac2d6f2c1f63d000d7fff03500aa375ac
> Reviewed-on: https://webrtc-review.googlesource.com/71621
> Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
> Reviewed-by: Zijie He <zijiehe@chromium.org>
> Commit-Queue: Brave Yao <braveyao@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23263}
Bug: webrtc:9178
Change-Id: I97d9150f7b9a4ed6671733b75613ea9c315d5c1d
Reviewed-on: https://webrtc-review.googlesource.com/77481
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23289}
Currently we prefer the last added rtp module that supports rtx, and
assume this is the HD stream.
If we suffer a network degradation and stop sending HD, the current
behavior will trigger RTX padding on an inactive stream, which is not
very useful.
With this change, we will prefer the rtp module that last sent media,
which will spread the load a bit across active media streams, but will
be biased toward the one with highest packet rate.
Bug: webrtc:8975
Change-Id: Id52865ccd5263722c66d327b8c80457f63b90385
Reviewed-on: https://webrtc-review.googlesource.com/77360
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23281}
This reverts commit 89653d5db46419d2a80898635cb27fed64898db2.
Reason for revert:
Tentatively revert since I believe this break remoting unittests on Asan/Tsan
https://chromium-review.googlesource.com/c/chromium/src/+/1063330https://chromium-swarm.appspot.com/task?id=3d8692bedcc85c10&refresh=10&show_raw=1
Original change's description:
> [desktopCapture] Unify the position info in DIP coordinates on Mac.
>
> On OSX, the logical(DIP) and physical coordinates are used mixingly.
> For example, the captured image has its size in physical pixels(2x) and
> location in logical(DIP) pixels. Same to the cursor position. This
> causes trouble when we check the relative position of image and cursor
> when there are multiple monitors with different DIP setting connected.
>
> This cl proposed a solution to use DIP pixel for any location info,
> i.e. top-left of a frame and cursor position. Also propose a method to
> get the current scale factor of a window across multiple monitors. And
> save the current scale factor in DPI of the capture frame.
> Then we can check relative position of cursor and frame correctly
> in DIP pixel and compose them in physical pixel.
>
> Bug: webrtc:9178
> Change-Id: I3c076aeac2d6f2c1f63d000d7fff03500aa375ac
> Reviewed-on: https://webrtc-review.googlesource.com/71621
> Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
> Reviewed-by: Zijie He <zijiehe@chromium.org>
> Commit-Queue: Brave Yao <braveyao@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23263}
TBR=zijiehe@chromium.org,jamiewalch@chromium.org,perkj@webrtc.org,braveyao@webrtc.org
Change-Id: Ica02365925623e21b256d20a21b5625e7ed6f49b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9178
Reviewed-on: https://webrtc-review.googlesource.com/77461
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23280}
