If the extension is negotiated, it will only be used if
the field trial WebRTC-Audio-SendSideBwe is enabled.
This allows simpler experimentation if it should be used or not.
Bug: webrtc:10309 webrtc:10286
Change-Id: I797e6f14c06d46189e40f6d09805c2e09afc015b
Reviewed-on: https://webrtc-review.googlesource.com/c/122542
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26689}
This is not a functional change. I've verified that the event_log_visualizer outputs the same bytes before and after the CL.
Bug: webrtc:10102, webrtc:10312
Change-Id: I49c4c847926078cefc9b72fe57fbdaebf76423e9
Reviewed-on: https://webrtc-review.googlesource.com/c/122844
Reviewed-by: Mirta Dvornicic <mirtad@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26685}
Removing simulcast stream support as it was broken.
Bug: webrtc:9510
Change-Id: I42ba285bbea81e6ffd5b1d1a1aec4e5eb0990b1e
Reviewed-on: https://webrtc-review.googlesource.com/c/123040
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26684}
There was a name collision with downstream test frameworks.
Bug: webrtc:9510
Change-Id: I7e37a8a54701ef4a47c687aec51f37523759f1b2
Reviewed-on: https://webrtc-review.googlesource.com/c/123044
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26683}
This will be used to investigate the effect of congestion window
pushback on bandwidth esimation. There is currently no data available
in event logs to analyze this in test runs.
Bug: None
Change-Id: I2397842e90fd4acab6306b03d1ee9daf62469ee3
Reviewed-on: https://webrtc-review.googlesource.com/c/121765
Reviewed-by: Konrad Hofbauer <hofbauer@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#26681}
This change does not include receive_timestamps for ACKs, because there is 1 problem.
That problem will be resolved in a separate change.
I am getting receive_timestamp errors that have to do with delta compression with optional fields.
Two failure modes that I noticed:
1) the base event does not have the timestamp: it crashes with length validation
# Check failed: base <= MaxUnsignedValueOfBitWidth(params_.value_width_bits()) (1820716 vs. 131071)
2) all events are null, it crashes with assert that X events were expected, but no events were deserialized.
Bug: webrtc:9719
Change-Id: I5d1bbb95dfd15ca7321667aad5e4d89c085e9c06
Reviewed-on: https://webrtc-review.googlesource.com/c/122360
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26668}
On NetEq level latency corresponds to delay and two terms can be used interchangeably here.
In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here:
https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm
Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on.
To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently
possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible.
Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length.
Bug: webrtc:10287
Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766
Reviewed-on: https://webrtc-review.googlesource.com/c/121700
Commit-Queue: Ruslan Burakov <kuddai@google.com>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26666}
Since it's a common pattern it makes sense to explicitly provide the
interface rather than reimplementing it every time it's used.
Bug: webrtc:9883
Change-Id: I4dca84bd7c8616fcbcbaba511718671a3668e743
Reviewed-on: https://webrtc-review.googlesource.com/c/122300
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26664}
This works around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89305, which
causes GCC to fail to build the code due to |thread_checker_| being const
there and not having a declared constructor.
../../api/ice_transport_factory.cc: In constructor ‘webrtc::{anonymous}::IceTransportWithTransportChannel::IceTransportWithTransportChannel(std::unique_ptr<cricket::IceTransportInternal>)’:
../../api/ice_transport_factory.cc:31:3: error: uninitialized const member in ‘const class rtc::ThreadChecker’ [-fpermissive]
IceTransportWithTransportChannel(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../api/ice_transport_factory.cc:45:28: note: ‘const rtc::ThreadChecker webrtc::{anonymous}::IceTransportWithTransportChannel::thread_checker_’ should be initialized
const rtc::ThreadChecker thread_checker_;
^~~~~~~~~~~~~~~
Bug: chromium:819294
Change-Id: I750e8cdd796b3b0e076de01194cf7de988ac4ce2
Reviewed-on: https://webrtc-review.googlesource.com/c/122820
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#26662}
In order to correctly close audio dump files, TestPeers have to be
destroyed after the call is finished.
Bug: webrtc:10138
Change-Id: I948e4e1844dfbffd1eef7926a4dd4d7631dbe632
Reviewed-on: https://webrtc-review.googlesource.com/c/122301
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26661}
This quality boost means that we sometimes drop a _lot_ of frames in the
base layer. It also interacts poorly with the bitrate adjuster since
even if frames are dropped they are often over-sized.
The setting still leaves the current behavior as default, but can be
changed using the WebRTC-VideoRateControl field trial.
Bug: webrtc:10155
Change-Id: I1a92ec69bab61b5148fe9d8bc391ac5ee1019367
Reviewed-on: https://webrtc-review.googlesource.com/c/122840
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26659}
Chromium's official builds set -D_FORTIFY_SOURCE=2, causing among other
things warnings about unused return values from stdlib functions.
We don't normally build "all" in that configuration, and so missed some
instances.
Bug: chromium:931227
Change-Id: I69820d4e639c5908e0092dded1dea39c51d45d6b
Reviewed-on: https://webrtc-review.googlesource.com/c/122560
Commit-Queue: Hans Wennborg <hans@chromium.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26657}
Actually, I don't think there is any strong reason to keep these
deps in `webrtc` target except some downstream projects need it.
Making a GN config for now.
Bug: webrtc:10306
Change-Id: Id714faeabf4daaf3cc88d1f6224ae89ca8715e48
Reviewed-on: https://webrtc-review.googlesource.com/c/122420
Commit-Queue: Jiawei Ou <ouj@fb.com>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26653}
This replaces the functionality provided by
AudioPriorityBitrateAllocationStrategy, removing the need provide that
component via injection in all clients using audio bitrate priority.
Bug: webrtc:10286
Change-Id: I3bafab56d24459d9d27dc07abffdc8538440a346
Reviewed-on: https://webrtc-review.googlesource.com/c/121402
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26651}
Set padding bit if the TransportFeedback packet contains zero padding.
Also write number of padding elements at the last position of the packet.
Bug: webrtc:10263
Change-Id: I8d17bc0e889f658ac383dec64ddcb95d438c9702
Reviewed-on: https://webrtc-review.googlesource.com/c/122240
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26646}
