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}
Modify cl/ a bit and add fieldtrialsstring on observer
not to break downstream projects.
---
WebRTC-DeprecateGlobalFieldTrialString/Enabled/ - part 14/inf
This cl/ passes field trials all the way from c++
to the android NetworkMonitorAutoDetect.java
Bug: webrtc:10335
Change-Id: Ic6842612eed36b684340f0f78f4087bee249cc50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36498}
---
Bug: webrtc:10335
Change-Id: Ied43770977465a0042541a61d29a9015c0b9cdc8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258622
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36520}
Now that FieldTrialsView is (almost) a supported object,
let downstream tests use the ScopedKeyValueConfig for
testing.
Bug: webrtc:10335
Change-Id: I7bf7577387f1123b473275990ca32b80a8ddf9bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258480
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36519}
This makes moving from sigslot to CallbackList slightly simpler in some
situations.
Bug: webrtc:11943
Change-Id: I5c6dafb8ac597a119b90b64f369fa9e6316e38da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258560
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36515}
A managed device might have camera access restricted, which results in
the following crash:
Caused by android.os.ServiceSpecificException: validateClientPermissionsLocked:1044: Callers from device user 0 are not currently allowed to connect to camera "1"
at android.os.Parcel.createException(Parcel.java:2085)
at android.os.Parcel.readException(Parcel.java:2039)
at android.os.Parcel.readException(Parcel.java:1987)
at android.hardware.ICameraService$Stub$Proxy.connectDevice(ICameraService.java:624)
at android.hardware.camera2.CameraManager.openCameraDeviceUserAsync(CameraManager.java:389)
at android.hardware.camera2.CameraManager.openCameraForUid(CameraManager.java:588)
at android.hardware.camera2.CameraManager.openCamera(CameraManager.java:516)
at org.webrtc.Camera2Session.openCamera(Camera2Session.java:359)
at org.webrtc.Camera2Session.start(Camera2Session.java:322)
at org.webrtc.Camera2Session.<init>(Camera2Session.java:298)
at org.webrtc.Camera2Session.create(Camera2Session.java:276)
at org.webrtc.Camera2Capturer.createCameraSession(Camera2Capturer.java:35)
at org.webrtc.CameraCapturer$5.run(CameraCapturer.java:272)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.os.HandlerThread.run(HandlerThread.java:67)
Change-Id: I5e7b8d238e9381d1f8a4fe9858e8eb480d578fa0
Bug: webrtc:13950
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258363
Commit-Queue: Xavier Lepaul <xalep@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36513}
There doesn't seem to be any tests currently running with
VideoToolbox H.264 codec.
Add a minimal test to make sure there are no regressions.
Bug: webrtc:13934
Change-Id: I664833d06e9b4f919b0662781891f5448e6057c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257922
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#36511}
