The RTCP mode is a send property for both send and receive channels. Send properties should be configured based on what peers support/prefer, which is described by the remote description (content).
Bug: webrtc:340041654
Change-Id: I18cd59e98aecfbbd8f4919b98381836184c10d77
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368980
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Lundqvist <tomasl@google.com>
Cr-Commit-Position: refs/heads/main@{#43449}
It works in the same way as the first packet received callback and can be used for latency measurements.
One important detail is that RTCP and probe packets are excluded from triggering the callback.
Bug: b/375148360
Change-Id: I5f99b565f96b622e864669cf227be5534aab0fc7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366644
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43309}
This entails passing in a PayloadTypeSuggester as a dependency. PT suggesting is still done according to the old method, but with new code.
Bug: webrtc:360058654
Change-Id: I12a7d2aa6aa482fb62ff3dfb34b9761ebb7dddef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361200
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42989}
These are aliases for cricket::Codec.
Also remove internal usage
Bug: b/42225532
Change-Id: I220b95260dc942368cb6280432a058159eec8700
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349321
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42194}
This reverts commit 1ae700a9233ed647e1b4080c0fcb48f61a0cca0a.
Reason for revert: Potential root cause of crbug.com/1504351
Original change's description:
> Make Codec::Matches also consider packetization
>
> If it's not considered it can lead to payload IDs erroneously being
> reused if the SDP is munged, see https://crbug.com/webrtc/15473#c10.
>
> Bug: webrtc:15473
> Change-Id: I195a06d556e8a57dbeeb946effc4e0f27cc930b0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326522
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41153}
Bug: webrtc:15473 chromium:1504351
Change-Id: I87fb671d76c3b17beb65124603cc040bb9bf4fa5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329201
Commit-Queue: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41285}
and unify algorithms a bit more.
BUG=webrtc:15214
Change-Id: Ie9903f3e56d25b1dc026367e8ae6817275faa07b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/328442
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41244}
If it's not considered it can lead to payload IDs erroneously being
reused if the SDP is munged, see https://crbug.com/webrtc/15473#c10.
Bug: webrtc:15473
Change-Id: I195a06d556e8a57dbeeb946effc4e0f27cc930b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326522
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41153}
...for signaling and worker thread members in BaseChannel classes.
Bug: webrtc:15099
Change-Id: I83611ed2564e143aca19d0f12ce060b77eb9d2a7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325260
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41041}
No functionality that depends on this information has been identified; no tests break when it is taken out.
Bug: webrtc:15224
Change-Id: I37298479c6b8a4acb82f59d32130c105371936b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324760
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41037}
It's possible that a peer can signal the same payload with multiple
packetization options. As such, we shouldn't try to fall back to default
packetization until we have considered all the alternatives.
Bug: webrtc:15473
Change-Id: I21772b4d8c53819d1c3105988551ebdbea0df045
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320241
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Auto-Submit: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Sergey Sukhanov <sergeysu@webrtc.org>
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40775}
If there happens to be an asymmetry between local and remote codecs we
shouldn't validate that there's a 1:1 packetization mapping for every
codec. It's sufficient to check that there's at least one matching
packetization per codec.
Bug: webrtc:15473
Change-Id: Ib4fc8fdd54bb4dccf96f0c802746c848e2deed83
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320440
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Auto-Submit: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Sergey Sukhanov <sergeysu@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40760}
following the previous change to rename the classes derived from
cricket::RtpParameters
Also rename ChangedRecvParameters to ChangedReceiveParameters.
BUG=webrtc:13931
Change-Id: Ia51dd39905a5cbb98162c3948930e43ccaf3786d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/314500
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40677}
There are no common functions between MediaSendChannelInterface
and MediaReceiveChannelInterface except media_type().
This allows us to remove the common superclass for the two interfaces,
making for a simpler class structure.
Bug: webrtc:13931
Change-Id: I82a12ca31f0dc62d7bd97bdda34ca37e59a5fd55
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306660
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40154}
This makes the handling somewhat more uniform, and is the same
for both video and audio channels.
Bug: webrtc:13931
Change-Id: I26605c56e069e8a34e03708d45eb27a6b7492130
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306100
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40107}
by not starting the receive stream whenever it is creating.
Instead, this is controlled by the direction of the media content.
BUG=webrtc:11013
Change-Id: Iaaa0ac0aa9f90a4be776a1348f53a0f9c2b84d99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304661
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40064}
This reverts commit 18c869bc36b342cd4a79947067e52a93a04a7808.
Reason for revert: Added a field trial that allows landing the code without affecting performance in prod.
This CL also incorporates subsequent CLs that also had to be reverted.
Original change's description:
> Revert "Use two MediaChannels for 2 directions."
>
> This reverts commit 8981a6fac3d665beac4a58b9453e6c39988a024f.
>
> Reason for revert: Quality regression detected.
>
> Original change's description:
> > Use two MediaChannels for 2 directions.
> >
> > This CL separates the two directions of MediaChannel into two separate objects that do not couple with each other.
> >
> > The notable API change is that receiver local SSRC now has to be set explicitly - before, it was done implicitly when the send-side MediaChannel had a stream added to it.
> >
> > Bug: webrtc:13931
> > Change-Id: I83c2e3c8e79f89872d5adda1bc2899f7049748b3
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288400
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#39340}
>
> No-Try: true
> Bug: webrtc:13931
> Change-Id: I791997ad9eff75c3ac9cd2e4bbacf5bc6c3a3a79
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295663
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39445}
Bug: webrtc:13931
Change-Id: I1318910a685188e2b846c9040e1efc04c2c894ac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296080
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39494}
This reverts commit 8981a6fac3d665beac4a58b9453e6c39988a024f.
Reason for revert: Quality regression detected.
Original change's description:
> Use two MediaChannels for 2 directions.
>
> This CL separates the two directions of MediaChannel into two separate objects that do not couple with each other.
>
> The notable API change is that receiver local SSRC now has to be set explicitly - before, it was done implicitly when the send-side MediaChannel had a stream added to it.
>
> Bug: webrtc:13931
> Change-Id: I83c2e3c8e79f89872d5adda1bc2899f7049748b3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288400
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39340}
No-Try: true
Bug: webrtc:13931
Change-Id: I791997ad9eff75c3ac9cd2e4bbacf5bc6c3a3a79
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295663
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39445}
This reverts commit a087f6f1c842f1d70ad207b44c48321ab60d2d95.
Reason for revert: Needed to roll back other CL
Original change's description:
> Add plumbing for video NACK to be coupled between channels.
>
> Bug: webrtc:13931, webrtc:14920
> Change-Id: I451869e295e099a1d08c0c80e481decd53149f1b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294382
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39373}
Bug: webrtc:13931, webrtc:14920
Change-Id: I19e176e75630313da470542e7ff1e89b6d717fc9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295664
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39432}
This CL separates the two directions of MediaChannel into two separate objects that do not couple with each other.
The notable API change is that receiver local SSRC now has to be set explicitly - before, it was done implicitly when the send-side MediaChannel had a stream added to it.
Bug: webrtc:13931
Change-Id: I83c2e3c8e79f89872d5adda1bc2899f7049748b3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288400
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39340}
With this cl, a packet is only parsed once in RtpTransport::DemuxPacket and the metadata is reused.
Extensions are still identified twice- one for demuxing based on mid. The second time in Channel::OnReceivedPacket in order to use extensions specific to that mid.
Bug: webrtc:7135, webrtc:14795
Change-Id: I50e3814af92ca4378f148876b20a54bcfac1e146
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290540
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39058}
This detaches the implementation (which is still merged)
from the objects used to interface to it.
Bug: webrtc:13931
Change-Id: I872ee10e4ed9fa432bfa231f723af1d3989d79d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288080
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38906}
The implementation here has a number of changes that force the callers
that called the "channel" functions into specific interfaces rather than
just letting C++ take care of it; this should go away once there stops
being a common implementation class for those interfaces.
Bug: webrtc:13931
Change-Id: Ic4e279528a341bc0a0e88d2e1e76c90bc43a1035
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/287640
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38888}
This allows callers to differentiate on whether they need the
channel for sending or receiving purposes.
Note: This CL is incomplete, in that many places cast the pointers
to the concrete subclasses "VideoMediaChannel" and "AudioMediaChannel", which are not split into sending and receiving APIs.
The long term goal is to make two MediaChannel-like class APIs, with distinct implementations, and let the RtpSender and RtpReceiver manage those objects, rather than keeping them in the RtpTransceiver.
Bug: webrtc:13931
Change-Id: I8d56defe2287bd6552b71571cc6a5ec842927fa4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/287040
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38844}
BlockingCall doesn't take rtc::Location parameter and thus most of the dependencies on location can be removed
Bug: webrtc:11318
Change-Id: I91a17e342dd9a9e3e2c8f7fbe267474c98a8d0e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274620
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38045}
This breaks the link from sdp_offer_answer.cc to channel.h.
Bug: webrtc:13931
Change-Id: I75608f75713bf4e69013ac5f5b17c19e53d07519
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261060
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36757}
Also eliminate FillBitrateInfo from the Channel object.
Bug: webrtc:13931
Change-Id: I5265b7629413a1ed04898272adf26708e2ee9b8d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260469
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36744}
Also apply IWYU to all .cc files in pc/, and correct BUILD file to match.
Note: Some files came out wrong when iwyu was applied. These are not included.
Bug: none
Change-Id: Ib5ea46b8fcc505414d0447cca7218ad3afc2e321
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/252280
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36064}
This is a follow-up to CL [1] to restore the check of whether updating
the demuxer criteria in the channel classes succeeded or failed.
[1] https://webrtc-review.googlesource.com/c/src/+/244700
Bug: webrtc:13536
Change-Id: If0e986bd4e4799e20be2b49f80abcc5a3e6825fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249940
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@google.com>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35862}
The interface is implemented by the ChannelManager and contains methods
to create and destroy media channel objects as used by a transceiver.
This will subsequently allow us to delete the channel objects from
the transceiver class where ownership really lies rather than from
the outside - which is currently required by some tests that keep
channel objects on the stack. We'll furthermore be able to do the
destruction asynchronously without additional Invoke()s as we do now
which will remove an Invoke when making sdp changes.
With introducing the interface, the following simplifications were made:
* ChannelManager constructed on the signaling thread.
Before, there was an Invoke in the context class, which existed
for the purposes of calling MediaEngine::Init() (which in turn is
only needed for the VoiceEngine). This Invoke has now been moved
into the CM (more tbd).
* The CM now has a pointer to the signaling thread (since that's the
construction thread). That allows us to remove the signaling thread
parameter from the CreateFooChannel methods.
* The ssrc_generator (UniqueRandomIdGenerator) instance for SSRCs moved
from SdpOfferAnswerHandler to the CM, as it's always used in
combination with the CM. This simplifies the CreateFooChannel methods
as well as a couple of other classes that have a CM dependency.
* Removed DestroyFooChannel related code from SdpOfferAnswerHandler since
the channel type detail can be taken care of by the CM.
Bug: webrtc:11992, webrtc:13540
Change-Id: I04938a803734de8489ba31e6212d9eaecc244126
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/247904
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35766}
...and one when destroying a channel object.
This CL removes Init_n() and Deinit_n() from the BaseChannel class.
Channel classes now use SetRtpTransport to do initialization and
uninitialization on the network thread.
Notably if an implementation has called SetRtpTransport() with a valid
transport pointer, it is required that SetRtpTransport be called again
with a nullptr before the channel object can be deleted.
In situations where multiple channels are created, this can mean
a substantial reduction in thread hops. We still hop to the worker
in order to construct the objects - this can probably be avoided
and SetChannel() is still a synchronous operation for the transceivers.
Furthermore, teardown of channel objects also still happens
synchronously and across network/worker/signaling threads.
Bug: webrtc:11992
Change-Id: I68ca7596e181fc82996e3e290733d97381aa5e78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246740
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35738}
Remove Init_w and Deinit(), both of which were wrappers around Invoke()
calls from the worker thread to the network thread.
Instead, replace them with Init_n() and Deinit_n() that are currently*
required to be called by external code in order to associate/disassociate
the channels with the transport.
This CL mostly moves things around in order to prepare for upcoming
changes, but it does change channel destruction in the following way:
- When destroying channels, we don't block the worker thread anymore
while uninitialization happens on the network thread. Previously
both signal and worker threads were blocked during the
uninitialization in the ChannelManager.
* In an upcoming CL, Init_n() and Deinit_n() will be called internally
from a different method that's always called on the network thread
when a channel is associated/disassociated with a transceiver. When
we're there, we will have removed several invokes that currently are
a part of constructing/destructing channel objects.
Bug: webrtc:11992
Change-Id: Ibc30447a40749ceb36d37834b0cfc5c5ea60e895
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246502
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35707}
This is a simple check for upcoming changes for media channels to
be able to check if the state on the network thread is consistent.
Bug: webrtc:11992
Change-Id: I8ed2d091ecf3869a66970fc4733aebf209c4ef82
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246681
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35706}
If a call to BaseChannel::SetPayloadTypeDemuxingEnabled does not result
in a demuxer criteria configuration change, we can avoid an Invoke
and speed up negotiations.
Bug: webrtc:11993
Change-Id: I80c894d7cc2a733ab84c1f4978f0c58c09a123a5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244920
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35649}
