Existing recipe code to trigger testers from builders assumes the bots belong to the same bucket.
Bug: b/218825531
Change-Id: I3cd6414f7e1bacc21d3443285d1217f6b90a6adf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259260
Reviewed-by: Christoffer Jansson <jansson@google.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36568}
While the target has a restricted visibility, since it was in rtc_base_approved
public deps, a lot of targets were able to bypass the visibility check.
So we remove the visibility restrictions and use the dependency explicitely
everywhere instead.
Bug: webrtc:8603
Change-Id: I94a03fdf7f94c54ab72081a58dd648e2cca73d17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258944
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36566}
There is a crash report from the Windows OS API
where it repro only win10, not a Win11.
Unfortunately, Microsoft can't access the dump file or
hasn't repro internally so we decided to disable the WGC
fallback use in the OS other than Win11 now.
Once the change (support WGC fallback) reaches to Microsoft Edge
and it produce crash report, Edge team will take the
dump file to the Windows OS API owner for Win10 level fix (or
bring the Win11 fix to Win10).
Bug: chromium:1312937
Change-Id: I5335e2c57076d4fab08e9c74ade599259cff10d7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258821
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36558}
XDG desktop portal utils implicitly rely on few portal interfaces.
This change makes those interfaces explicit.
Bug: chromium:1291247
Change-Id: I3c300f33d04bfa8857ac9f1f9d634dbfc077e591
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258720
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36557}
Versions of Windows before Win11 will crash when `CreateForMonitor` is
called, but the system has no attached displays. This can be avoided by
adding a check to ensure at least one display is found before we return
true in `IsMonitorValid`. Previously we would early return `true` if the
"monitor" we were checking was the `kFullDesktopScreenId`.
Bug: chromium:1316478
Change-Id: I2562fe3834db574cf3706ee1d604472ac03f9ff3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258920
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36555}
`pending_delete_` was being used to protect from referencing a
potentially bad `port_` pointer. We now use a WeakPtr for the port
reference, which we clear inside of the Destroy() method. This means
we don't need both flags.
Bug: webrtc:13892
Change-Id: I9427829444486e97d30752893ba2a30b153a70e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258980
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36554}
To mitigate race between ~ChannelSend and task created in ProcessAndEncodeAudio.
as described in the comment next to the task queue member.
Bug: b/228933184
Change-Id: Ia0efd050c76a4539dc2525ef8efc065fab96861c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258983
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36553}
DSCP is controlled by the spec-compliant API
RTCRtpEncodingParameters.networkPriority[1]. It already has a default
value that is the same as when DSCP is disabled.
- If you want non-default DSCP default values, you need to set
networkPriority and shouldn't need to set a non-standard googDscp flag
for it to have an effect.
- If you want the default DSCP value, you wouldn't change
networkPriority and so you don't care if enable_dscp is true... you'll
get the default regardless.
Drive-by: This CL also adds crbug references to other goog flags.
[1] https://w3c.github.io/webrtc-priority/#dom-rtcrtpencodingparameters-networkpriority
Bug: chromium:1315574
Change-Id: I15a0470fa04f55e2534cee0d240eeb03446c2de6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258940
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36550}
This removes use of the SignalClose sigslot. This CL includes thread
checks for the callback list and updates some call sites to unsubscribe
from events before deletion or detaching from a socket instance.
Bug: webrtc:11943
Change-Id: Ib66d39aa5cc795b750c9e3eaa85ed6af8b55b2b5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258561
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36540}
This CL adds flag "max_queue_time", e.g:
WebRTC-SlackedTaskQueuePacedSender/Enabled:true,max_queue_time:75ms
If the PacingController's ExpectedQueueTime() is greater than or equal
to "max_queue_time" then we will use high precision delayed tasks to
ensure a smoother (less bursty) pacing of packets.
This should only get triggered in ultra high definition scenarios or
temporarily during key frames being sent. I have confirmed manually that
with the flag set to 75 ms I get low precision when not sending key
frames and temporarily get high precision for 5-15 delayed tasks during
the sending of a key frame.
Bug: webrtc:13957
Change-Id: I3c8aeba5fe18812ed0187610cd3f92a375bc6f18
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258623
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36538}
Adds two metrics for stereo detection:
- An enum indicating whether the last 10 seconds contained persistent stereo content or not, logged every 10 seconds.
- An enum indicating whether any persistent stereo content at all has been detected, logged at the end of the AEC lifetime.
These metrics allow us to assess:
- What proportion of all audio is treated as stereo.
- What proportion of sessions encounter any significant stereo content. If this is unexpectedly high, the stereo detection code may need fine tuning.
Metrics are only logged for component lifetimes exceeding 5 seconds: This is to avoid brief AEC lifetimes due to internal resets etc within APM.
Corresponding Chrome CL for XML histogram declarations:
https://crrev.com/c/3579317
Bug: chromium:1295710
Change-Id: I93e2bf74588cf4bb2a8922dbfad079bccab01456
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258760
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36537}
This is just to reduce confusion since StunMessage and StunRequest
instances are frequently used together and message objects are often
configured from within request objects (which makes the name confusing).
Bug: none
Change-Id: I8bf5e774a5149239dd3023817614d411633bf583
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258484
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36533}
This removes the circular delete/remove pattern between the StunRequest
and StunRequestManager whereby deleting a request would call the
manager from the dtor to do a lookup+erase from the map. Instead
the operation of removing from the map, equals delete and is controlled
by the manager (owner) class.
Bug: webrtc:13892
Change-Id: I1920ac4b98636d38b851f4c2057026bfbd392584
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258660
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36532}
This cl/ fixes another 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.
Th recent fix to add IsAdapterAvailable, https://webrtc-review.googlesource.com/c/src/+/257400
contained a bug in that the adapter_type_by_name_ map was not
reset either on disconnect or Start/Stop.
This cl/ addresses that including unit test.
It also de-obfuscates NetworkMonitor so that it always
calls NotifyOfActiveNetworkList on startMonitoring even
if list.size() == 0. This should not matter but makes
code easier to understand.
Bug: webrtc:13741
Change-Id: I438b877eebf769a8b2e7292b697ef1c0a349b24f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258721
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36530}
* Make StunRequest::manager_ a reference, inject ref at ctor time.
* Make other member variables private.
* Mark methods that are only used for testing with "ForTest"
* Add RTC_GUARDED_BY for member variables and thread checks.
* Remove/reduce 'friend'-ness between classes.
* Use std::unique_ptr for owned and passed message pointers.
* Rename `requests_` to `request_manager_` (type: StunRequestManager)
Bug: webrtc:13892
Change-Id: I3a5d511b3c2645bb6813352d39e9fefe422dd1de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258620
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36529}
Remote desktop wrapper needs to create a barrier on when the screencast
portal is done (either succeeded or failed). This change adds an initial
enum to differentiate it from other values. CL also generalizes the
helper `PortalFailed` to `OnPortalDone` so as to account for both
failure/success scenarios.
Bug: chromium:1291247
Change-Id: I188f72533e75a88c9b30ce2bb093dae548cef7b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258540
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36526}
See go/deprecating-media-constraints for motivation.
Setting this min bitrate is necessary for BWE to work properly when
sending screencast in low BW scenarios. The value 100 kbps appears to be
a sensible default in practise (this is the value used by Google Meet).
In order for apps not to have to rely on non-standard APIs
(googScreencastMinBitrate) for BWE to work properly, we change the
default to 100 kbps. This will unblock deprecating and removing legacy
mediaConstraints.
A kill switch is added in case this causes any unforeseen issues, but if
all goes well we can remove the kill switch in the next milestone.
Bug: chromium:1315155
Change-Id: I02b4eb0dfb26f934e678760313a0423f412512c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258681
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36523}
