The fallback implementation currently returns "...(fallback from
unknown)" since ImplemenationName() is deprecated. Fix this by
using GetDecoderInfo() to determine the implementation name.
Bug: webrtc:12271
Change-Id: Ifa1d97678cd1bf05d9b5a10b73da23c4d54a1e05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257901
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36440}
to support clients (e.g. RTCPReceiver) that collect and report RTT per sender ssrc.
Bug: webrtc:8239, webrtc:13853
Change-Id: I907fb35277b0f23bbe9f2cd2ef979ce0fb1f9338
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257440
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36439}
Lines like 'deps = [ "foo" ]' would fail to be fixed.
Just insert the new dependencies in front and let the formatter have fun
with this after.
Bug: None
Change-Id: I747925cd0a1de93715a00b9ff3490b555f237e97
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257906
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36429}
Recent Clang versions have enhanced -Wunused-but-set-variable which now
warns about this.
Bug: chromium:1309955
Change-Id: I7a9d2175e6314fe8133cf7a77eb00bd4a22a23c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257300
Reviewed-by: Jonas Oreland <jonaso@google.com>
Auto-Submit: Hans Wennborg <hans@chromium.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36418}
New folders will be created under infra/ like infra/specs/ for the tests recipe config.
Bug: webrtc:13899
Change-Id: Ic463c917a65358f3b3b3820cb5633133d5e4c5be
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257304
Reviewed-by: Christoffer Jansson <jansson@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36415}
In r36379 a change to per-resolution setting of denoising was introduced
that unintentionally enabled denoising on lower resolutions in the case
that VideoCodec::VP9()->denoising was false.
The CL makes sure the per-resolution setting are only allowed to
disable denoising, not enable it.
Bug: webrtc:13888
Change-Id: Ice07a5a7d27798dc2182a40af0ec521bde6210b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257303
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36412}
This cl/ fixes a race condition with the recent additions
to NetworkMonitorAutoDetect (getAllNetworksFromCache).
The getAllNetworksFromCache-feature uses the by the Android team preferred way of
enumerating networks, i.e to register network listeners.
This however introduces a unpleasant race condition like this:
1) network.cc discover rmnet0
2) BasicPortAllocator tries to create UDP port on rmnet0
- This fails as BindSocketToNetwork requires a android handle.
3) NetworkMonitorAutoDetect gets callback with rmnet0
4) BasicPortAllocator tries to create TCP port on rmnet0
- This succeeds.
5) Since rmnet0 has one working port, there will not be
any new ports created on that network
=> We end up with a TCP only connection :(
---
By impl. IsAdapterAvailable, we make sure that the network
will not be used by BasicPortAllocator (or anyone else!)
until we support binding to it.
The IsAdapterAvailable was implemented for IOS,
and has test coverage using FakeNetworkManager.
This cl/ is default enabled with the kill-switch
WebRTC-AndroidNetworkMonitor-IsAdapterAvailable.
Bug: webrtc:13741
Change-Id: I7c2cb7789660fd2e082c214d00e50c894666b07c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257400
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36406}
When resetting several streams in sequence, only the first stream will
be included in the first RE_CONFIG chunk as it's created eagerly
whenever someone calls ResetStreams. The remaining ones are queued as
pending. When the first request finishes, the remaining ones should
continue to be processed, but this wasn't done prior to this commit.
This would only happen if two streams would be reset with shorter time
between them than a RTT, so that there would be an outstanding request
forcing the second reset to be enqueued.
Bug: chromium:1312009
Change-Id: Id74b375d1d1720406a3bca4ec60df5780ca7edba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257306
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36404}
Change adapts the `base_capturer_pipewire` so that a portal can be
injected in the capturer. This allows the remoting to inject its
own portal for the purpose of capturing desktop stream as long
as the injected portal provides implementation of the new interface
that is added as part of this change.
Additionally, a method has been exposed on the capturer to get
details about the portal session so that the remoting
implementation can use the same underlying session for controlling
inputs on the remote host.
Finally, desktop capturer interface is extended with a generic
method `GetMetadata` that is used to retrieve session related
information by CRD and relay it over to its input injector. Clients
provide override for the method and it eventually invokes the
underlying `GetSessionDetails` method on the portal instance.
Bug: chromium:1291247
Change-Id: I0dbd154eb16d4149f967c4a818eea51e7e6eb9a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257000
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36399}
Default holdback-window for non-prio packets is now 5ms, or the expected
pacing time for 3 packets if lower.
This brings wakeup frequency in line with legacy pacer at medium to low
packet rates.
Bug: webrtc:10809
Change-Id: I4045c40ae6b6d50f1ea049f3a26768023f77ec3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257301
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36397}
This was available in the beginning, as a way to increase the chance of
a message sent with partial reliability to be delivered, by avoiding it
to be fragmented in too small fragments.
This however added a few downsides:
* Packet efficiency goes down, as the entire MTU isn't always used
* Complexity increases when adding message interleaving, since if one
stream refuses to produce messages, but there is another stream with
a very small message that could fit in its place, it should be used
instead.
Removing this feature altogether is much easier. It's hard to defend.
Bug: webrtc:5696
Change-Id: Ie2f296e052f4a32a281497d379c0d528a2df3308
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257168
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36396}
RFC8831, section 6.7 states that closing a data channel MUST be signaled
as resetting an outgoing stream, and that will ensure that all messages
are either delivered or abandoned before the stream is reset. In the
current implementation, dcSCTP has opted to abandoned any queued
messages that haven't been partially sent.
And this CL simply adds more documentation around this choice. It's
subject to change and a client implementation shouldn't depend on any
such behavior as the RFC allows the implementation to decide.
Bug: None
Change-Id: I60305fe396a6a3f494d823c71e092acfeb6075b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257167
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36395}
This is to aid with catching issues whereby a connection object might
have a bad reference back to a port object, e.g. inside of an async
callback.
Bug: webrtc:13892
Change-Id: I56503fedc2865919713b10f236ce023554c68ded
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257164
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36394}
This use case was missing test coverage and sufficient comments in the
code.
Bug: None
Change-Id: I95b54a64f714b68a347fdbeef79eb38e715adbc3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257166
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36393}
This cl adds a new field trial parameter to WebRTC-Bwe-EstimateBoundedIncrease that allows the delay based estimate to immediately increase to the upper link capacity estimate.
Bug: none
Change-Id: I875121a41f65cc8e76bb87bbf421731ba6b4551b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257142
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36392}
* tools_webrtc/PRESUBMIT.py is only checking the licence which is already done here:
38f35db4d4:PRESUBMIT.py;l=913;bpv=1;bpt=0;drc=4fc9bd9f69a0d88889d86d0cc9f8e27406e8a342
* sdk/android/PRESUBMIT.py was added before 'git cl format' was required from the root PRESUBMIT.py:
https://codereview.webrtc.org/2377113003
Bug: webrtc:13895
Change-Id: Ia5ea2529c36ceebfd7d4e6a6a72352bd30c573b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257280
Reviewed-by: Christoffer Jansson <jansson@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36391}
