`cached_certificates_by_transport_` is used on the network thread, but
can be cleared from the signaling thread. To fix the race where clear
happens at the same time as stats collecting, a mutex is added.
This mutex should very rarely be contended in practise since
ClearCachedStatsReport() typically only happen during renegotiation
(e.g. when someone joins/leaves) and getStats only happens once per
second or less (typically).
NOTRY=Everything passes except unrelated purple bot
Bug: webrtc:14510
Change-Id: Iaf539a5cc8c87184fa0a87b9c889a13b941a9ad1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277620
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38262}
Reasons:
1) It is not used by `PeerConnection` (only in tests)
2) We have no plans on using it
3) The code is functionally untouched since many years
Bug: b/249972434
Change-Id: I1d30edd34231f25d86e8495ff71f1786ba2b0a1c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277445
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38260}
Early return will cause `call` to be destroyed outside the worker thread, which gives confusing error messages when all you did was type the wrong path to the input file :)
Bug: webrtc:14508
Change-Id: I029910d8da4bc7b08dafd02cb5ebf88d9c7afa59
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277443
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38254}
This is to keep the deprecated VideoReceiver separate from the
implementation used by VideoReceiver2 before updating
VCMDecoderDatabase to have ownership of the registered decoders.
Fixing typo (DataBase->Database) in the name of the remaining class.
Bug: webrtc:14486, webrtc:14497
Change-Id: I5ee755921454b0831b3af6d0161f5b48c7c60540
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276781
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38247}
This cl/ implements configuring of encode resolution
in the video_stream_encoder (webrtc_video_engine) in
a way that is independent of frame resolution (i.e
not using scale_resolution_down_by).
The cl/ reuses the VideoAdapter as is, and hence
the output resolution will be the same as it is today.
Anticipated further patches
3) Hook up resource adaptation
4) Let VideoSource do adaption if possible
Bug: webrtc:14451
Change-Id: I881b031c5b23be26cacfe138730154f1cb1b66a8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276742
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38245}
This updates VideoReceiveStream2::Stop() to symmetrically tear down
state that's built up in VideoReceiveStream2::Start().
Bug: webrtc:11993, webrtc:14486
Change-Id: I41f4feea5584e5baaeed2143432136f8b9761321
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272537
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38244}
When loss rate is above a certain threshold, set instant_limit = 500 - 1000 * average_loss_rate, which returns 200kbps at 30% loss rate, or 100kbps at 40% loss rate. When the loss rate is above 50%, use the min_bitrate from send_side_bandwidth_estimation.
The high_loss_rate_threshold is set to 1.0, so the change is not activated by default.
Tested the change with hamrit, when average loss rate is above 50%, bandwidth backed to 10kbps, and it took ~10s to ramp up to 1.5Mbps.
https://screenshot.googleplex.com/7dvPoWa2b5SgMSL
Bug: webrtc:12707
Change-Id: I5eea04ef709a183bdf696246094dbd4a204e48f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272061
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38243}
This cl move VideoEncoderConfig from api/ to video/config.
VideoStreamEncoderInterface and VideoStreamEncoderObserver
are moved as collateral.
brandt@ think that the reason these were in api/ in the
first place had to downstream project.
Functionality wise, this is a NOP, but it makes it easier
to modify the encoder (config).
Bug: webrtc:14451
Change-Id: I2610d815aeb186298498e7102cac773ecac8cd36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277002
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38242}
MaybeInitializeCapture may overwrite the render configuration of a concurrent render reinitialization, leading to a second render reinitialization on the next render processing call.
See bug description for details.
Tested: Verified bitexactness offline (single-threaded) on a large number of aecdumps.
Bug: webrtc:14495
Change-Id: I9b70b454ce1c27859c3414c9c9ec89b7bbe35559
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277380
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38241}
This change adds support to allow ChromeOS capturers to also pass a
WindowId with a source. This WindowID can be used to help allow plumbing
and passing an Id that the capturing process knows about, in case it
wants to use any in-process capturing logic.
Bug: chromium:1273189
Change-Id: Ibcf494a75aec06eb1c44e6ff5fbdd9e2952e9b7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267086
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38238}
This cl/ changes so that the EncoderStreamFactory is
not created inside WebRtcVideoSendStream (webrtc_video_engine).
The benifit of this is that the VideoStreamEncoder can then
amend the EncoderStreamFactory with state (and types)
w/o exposing it in VideoEncoderConfig.
I.e as an alternative to changes done inside
https://webrtc-review.googlesource.com/c/src/+/276742.
The fake_webrtc_call is modified to (if needed) create
it's own EncoderStreamFactory if needed.
Note: this cl/ will have to be merged with with
https://webrtc-review.googlesource.com/c/src/+/277002.
Bug: webrtc:14451
Change-Id: I3d896b227d39725ba6409622e8d09d14bd45d5fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277160
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38237}
The experiment has been approved for a full launch. Changing the
default value so that no decoder is created before the stream starts.
All decoders are created lazily on demand when we receive payload
data of the corresponding type.
Bug: chromium:1319864
Change-Id: Ifb412bbe49a7577a45c340496d5b8572ebc1ba44
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277120
Auto-Submit: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38232}
This cl/ is a NOP refactoring,
moving the EncoderStreamFactory from within webrtc_video_engine.cc
into own file in video/. simulcast.cc is collateral.
Bug: webrtc:14451
Change-Id: Ia69b9241d8cd8a12be6628d887701f2e244c07cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276861
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38224}
As mentioned in [1] declarations and definitions of the same symbol
should be part of the same library.
For some old code, this is not the case, and this can lead to hard to
debug linker errors like the ones from –warn-backrefs.
This CL adds the dependency to the defintion of call::Create() to
a target that uses it (and depends on the declaration from
call:call_interfaces).
In the future, call:call_interfaces should be removed entirely.
[1] - https://webrtc.googlesource.com/src/+/refs/heads/main/g3doc/style-guide/h-cc-pairs.md
Bug: None
Change-Id: I5f8fb6fa79815f1ff6b5199b9c682d7c9e73b616
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276941
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38221}
Ability to emulate degraded networks using DegradedCall has not
been covered by tests and it is crashing due to DCHECKs.
Fix threading issues so this no longer crash.
Bug: None
Change-Id: I9276dfb1f71762faa02146af0bfaab713bebb7f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276060
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#38216}
