This calls out the fact that SetChannel() is only used on M-section activation; ClearChannel is called on deactivation, and we never change the channel while a transceiver is active.
Bug: webrtc:13931
Change-Id: I3a3bfeec7c1d27d98c3f94a9401bee2130754ed7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260461
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36709}
This makes it clearer which modules set the channel.
Also remove GetChannel() from PeerConnection public API
This was only used once, internally, and can better be inlined.
Part of reducing the exposure of Channel.
Bug: webrtc:13931
Change-Id: I5f44865230a0d8314d269c85afb91d4b503e8de0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260187
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36695}
This is an implementation API, user classes should in principle
only use the channel_interface.h
Bug: webrtc:13931
Change-Id: I85c285217858dc087c90a50792e980f731f4439f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260185
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36674}
Prior to this CL, calling RtpTransceiver::SetChannel() with null
arguments would cause the receiver's track to end. This is wrong,
because the channel can be nulled for other reasons than the transceiver
being stopped/removed - such as when the transceiver is rolled back but
still in use. Also, stopping a transceiver will end the track, so we
should simply ensure to always stop the transceiver when that is needed.
This CL makes sure that the transceiver is stopped or stopping in all
appropriate places, allowing us to remove the ability to end the source
for any other reason. A side-effect of this is that:
- The track never ends prematurely, fixing https://crbug.com/1315611.
- Removed transceivers are always stopped, fixing
https://crbug.com/webrtc/14005.
This CL fixes the issue of track being ended in the ontrack event when
running https://jsfiddle.net/henbos/nxebusjm/.
- We don't have WPT test coverage for this, so I'll add that separately.
With SetSourceEnded() removed, some stopping/stop in response to
rejecting locally SDP munged content had to be added in order not to
regress the existing test coverage for this:
*PeerConnectionInterfaceTest.RejectMediaContent/1
Bug: chromium:1315611, webrtc:14005.
Change-Id: I21f30a1259e51324066dc84f72a72485b9e0fadc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260180
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36669}
This better reflects the ownership passing of AddTrack, and is more
consistent for RemoveTrack.
Bug: webrtc:13980
Change-Id: Ide5baccf15fc687a4e092f8831ce8c0fea46604e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259740
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36603}
This cl/ adds the feature actually injecting a FieldTrialsView into
PeerConnectionFactory, or into a PeerConnection or both.
The field trials used for a PeerConnection is those specified in
PeerConnectionDependencies. Otherwise will those from
PeerConnectionFactoryDependencies be used (and until we're finished with
this conversion, the global string fallback is used as last resort).
Note that it is currently not possible to create 2 FieldTrials
objects concurrently...due to global string,
so this cl/ is mostly (but entirely) for show, i.e one _can_
realistically inject them into a PeerConnectionFactory.
Bug: webrtc:10335
Change-Id: Id2e60525f48a1f8293c1dd0be771e3ed03790963
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258134
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36578}
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}
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}
Anything linking to //third_party/jsoncpp is hiding deprecated usage
warnings, so these were not discovered earlier.
Bug: chromium:983223
Change-Id: Id0ade4ca016f19db16377dbeeb756358a7e94fa2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258124
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36463}
Anything linking to //third_party/jsoncpp is hiding deprecated usage
warnings, so these were not discovered earlier.
Bug: chromium:983223
Change-Id: Ib527710b2688d691250d2b9f4894a9e6726d148f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258123
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36458}
Avoids using webrtc::GlobalMutex. Since state is allocated on first
use and never destroyed, we avoid an exit-time destructor when
building with absl::Mutex.
Bug: webrtc:11567
Change-Id: Ib9c6480ab0474e37a853460115b35d961b93009c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258080
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36455}
This was a side effect of testing out the "gn_check_autofix.py" tool
after running "apply-iwyu -r" on a few files.
Seems worth committing.
Bug: none
Change-Id: I3df446c640d4c4e3d6b15eddbdf66a1a40135f69
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258024
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36446}
This CL replaces those references with the smallest set of targets
that can satisfy the linker dependencies revealed by building the
"all" target.
Bug: webrtc:13634
Change-Id: Ia778630b18e1164138c41d245c3c8effed67f8e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257282
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36445}
This explores the theory that targets that have no files, just
dependencies, are unnecessary.
Bug: webrtc:13805
Change-Id: I1feb50cf3886128031af8970eae361e35fb052c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256974
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36363}
convert rtc_base/network and collateral.
This also remove last usage of system_wrappers/field_trials
in p2p/...Yay!
Bug: webrtc:10335
Change-Id: Ie8507b1f52bf7f3067e9b4bf8c81a825e4644fda
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256640
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36357}
If an instance of AudioRtpReceiver was initialized with a valid media
channel pointer (i.e. SetMediaChannel() was not being called), then
OnChanged() notification would not be handled correctly.
This fixes the issue by making sure the safety flag is marked as
'alive' when [re]starting the media channel.
Bug: webrtc:13854
Fixes: webrtc:13854
Change-Id: Iaa5cfeb4036bfc9dc2efbfa9e1319d508ab151a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256361
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36290}
