This CL fixes two issues with the old way targetBitrate was reported:
1. The target is per encoder, i.e. per SSRC, but the old way to report
it was per sender and was approximately the sum of all encodings'
targetBitrate in most cases.
2. The old value did not come directly from the VideoBitrateAllocation
and tended to be greater than the sum of all targets (don't know
why).
We know the old value was wrong and the new value correct because
the actual bytes produced by the encoder closely matches the configured
target, which wasn't always the case with the old metric implementation.
Tested with unit tests and manually in Chrome by going to
https://henbos.github.io/codec-quality/src/index.html and ensuring
target ~= actual bytes produced. It also matches the debug logging of
video_stream_encoder.cc.
Bug: webrtc:42225524, chromium:392424845
Change-Id: I7a6f69e053ebc3fd972c2c4b7712750e721c0acc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376460
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43854}
We should use the Timestamp type, rather then int64, to store timestamps. In https://webrtc-review.googlesource.com/c/src/+/365001/ an additional int64 timestamp was added (last_sender_report_timestamp_ms).
This CL fixes the new timestamp, as well as other similar timestamps in MediaReceiverInfo (last_sender_report_utc_timestamp_ms and last_sender_report_remote_utc_timestamp_ms).
Bug: webrtc:372393493
Change-Id: I0e473730e85a69ec595b421e2c3db920364008eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365641
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43248}
Add an environment clock timestamp to SenderReportStats and make it visible in rtc_stats_collector.cc. This make it possible to use the pc->GetConfiguration().stats_timestamp_with_environment_clock() flag to decide which timestamp to use when creating a RTCRemoteOutboundRtpStreamStats object.
This CL is the third (and possible the last) of a series of CLs that aim to replace the UTC timestamps in RTCStats objects to Environment clock timestamps. The other CLs where https://webrtc-review.googlesource.com/c/src/+/363946 and https://webrtc-review.googlesource.com/c/src/+/364782.
When Chromium and Google internal uses of RTCStats are updated to set the stats_timestamp_with_environment_clock configuration, the flag can be deleted.
Bug: chromium:369369568
Change-Id: Ic0b07d7b012505267bd6516f19a9ba90df4cafab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365001
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43206}
I missed one timestamp in https://webrtc-review.googlesource.com/c/src/+/363946, meaning that the config flag that was added do not yet work for all timestamps in RTCStats objects. The RTCRemoteOutboundRtpStreamStats still has UTC timestamps even if the config flag is set.
I will solve this by saving both an UTC (existing) and env (to be added) timestamp, and then let rtc_stats_collector choose timestamp based on the value of the config flag (just like RTCRemoteInboundRtpStreamStats is done in the 363946 commit).
Before adding the new env_ timestamp I want to make this change. I rename the existing timestamp to show what epoch it uses (NTP or UTC). This will later make it clear which timestamp is which.
So this CL will make no logical change, just renaming members.
I only need to rename the last_sender_report_timestamp_ms, but opted to rename the remote timestamp as well, to be consistent with the naming convention I add in this CL.
Bug: chromium:369369568
Change-Id: Icfe7cf274995b39799e1478a1bb8cdf5134f0b16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364782
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43194}
Add media config for using environment monotonic timestamps (i.e. not UTC) in RTCStats constructor, and implemented the usage of the flag.
Bug: chromium:369369568
Change-Id: Ia93d048742c28af201164fe7b2152b791bb6d0b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363946
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Cr-Commit-Position: refs/heads/main@{#43156}
Move it away from the "proprietary" SSL_CIPHER_get_id and looking up the cipher based on that towards SSL_CIPHER_standard_name.
SSL_CIPHER_get_id and the associated GetSslCipherSuite API is kept around for
WebRTC.PeerConnection.SslCipherSuite.*
UMA metrics and metrics compability (despite not yielding the IANA ids it promises).
BUG=None
Change-Id: Iaa357e3e31dc90abea688cf6ca10c0b40582ef38
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363202
Reviewed-by: David Benjamin <davidben@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43097}
These are required by the Perfetto API and the missing argument prevents
the use of Perfetto.
Bug: webrtc:15917
Change-Id: Ie40c0344dc9d8cd40f7c751b133d150b975a33c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347702
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#42147}
which was using the audio type to generate the id. Safe change
since the id is supposed to be random.
BUG=webrtc:12529
Change-Id: I9909c6d320f6f9239f0466599eba1f0eacf00adf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347683
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42142}
following the audio changes. Note that RTT-related fields require
DLRR and are not implemented yet.
BUG=webrtc:12529
Change-Id: I3f9449fbe876a1b282a32f2bcebe1cf3e10989bf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346580
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42069}
Switch to type_name() for things like logging since `type()` will
change to returning an enumeration value.
The functional change that this has is that log statements and
Connection::ToString() (used for logging) will contain "host"
instead of "local" and "srflx" instead of "stun".
Bug: webrtc:15846
Change-Id: I35c50d026e4578a25d51765d59c6f2e01b850c94
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339180
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41757}
This is a follow up to a previous CL that removed direct dependency on
the `cricket::` string globals.
Bug: none
Change-Id: I4d839a36739fc4694ce81b72ee036e83dae580df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335420
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41623}
This removes several references across the code base that depended on
the global string constants.
Bug: none
Change-Id: I007bd4b195c35261039f655f1a8f52e632c3691f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335320
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41578}
Same method, different name. Unblocks replacing RTCStatsMember<T> with
absl::optional<T>.
Bug: webrtc:15164
Change-Id: I251dd44d3b0f9576b3b68915fe0406d1b3381e5c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/334641
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41573}
which avoids those stats on datachannel-only or video-only connections.
Note that a receiver always exists, regardless of the transceiver direction.
BUG=None
Change-Id: I1ef33a8446fafe2978ac603e658e67d51d7af904
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330441
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Fredrik Hernqvist <fhernqvist@google.com>
Cr-Commit-Position: refs/heads/main@{#41423}
This test drives the new tools_webrtc/remove_extra_namespace.py tool.
Bug: None
Change-Id: I9b590aa1213e4cace2d64d555f4dafd893f03606
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327021
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41141}
which is present if a fec mechanism like FlexFEC is negotiated
spec change:
https://github.com/w3c/webrtc-stats/pull/765
BUG=webrtc:15250
Change-Id: I7d71d49fab0153d734f22831e6684d2acfc647fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/314981
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40514}
The existing equality check did not always work since content_type
is sometimes overloaded with extra internal information such as simulcast layer index. Fix by using the videocontenttypehelpers::IsScreenshare helper method.
Bug: webrtc:15381
Change-Id: I2fe84e7f036ea2c223e4fa6dd58af1c4c0bcfbdb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312261
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40448}
which means this will not show up in getStats inbound-rtp/outbound-rtp
until the encoder/decoder is known. This has implications in particular
for inbound-rtp where the value is currently "unknown" until video
frames have been received.
This is safe to change as the previous change to gate
decoderImplementation behind getUserMedia access already broke
the assumption that the field is always string.
BUG=webrtc:14906
Change-Id: Ie6040ada3656e80f792c0c32c1b86ad1d6609d3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293600
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40334}
filtering out the -1 value as it is done for "legacy" stats.
Also change the protocol and don't use "udp" and "tcp" which are misleading since the datachannel protocol is user-supplied.
BUG=webrtc:15071
Change-Id: I45d735fcf30144969630f5b8a91b40f12585bbfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300483
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40333}
specified in https://github.com/w3c/webrtc-stats/pull/762
and take FlexFEC into account for receive statistics.
BUG=webrtc:15250
Change-Id: Id85775ab1f29487d5b8bf478da6e22071005901a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294881
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40325}
This is a reland of commit ccc87ea3c625e43ab138e00ba2ef1a2d99756199
Downstream project has been updated.
Original change's description:
> [Stats] Remove enum-like structs in favor of strings.
>
> Due to a limitation of RTCStatsMember<T> not supporting enums, as well
> as the fact that in JavaScript enums are represented as basic strings,
> the stats enums have always been represented by T=std::string.
>
> Now that we have WebIDL-ified[1] all RTCStats dictionaries and enum
> values are simply string-copied (example: [2]) it seems safe to assume
> that "stats enums are just strings" is here to stay.
>
> Therefore there is little value in having C++ structs that look like
> enums so I'm deleting those in favor of std::string operator==()
> comparisons, e.g. `if (rtp_stream.kind == "audio")`. This removes some
> lines of code from our code base.
>
> I mostly want to get rid of these because they were taking up about 20%
> of the rtcstats_objects.h real estate...
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_stats_report.idl
> [2] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_stats_report.cc;l=667;drc=cf34e84c9df94256abfb1716ba075ed203975755
>
> Bug: webrtc:15245
> Change-Id: Iaf0827d7aecebc1cc02976a61663d5298d684f07
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308680
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#40295}
Bug: webrtc:15245
Change-Id: Ibc7aeb518ed0bd7f1d725f140132c99e5a89bcf3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308880
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40305}
This reverts commit ccc87ea3c625e43ab138e00ba2ef1a2d99756199.
Reason for revert: Breaks downstream project
Original change's description:
> [Stats] Remove enum-like structs in favor of strings.
>
> Due to a limitation of RTCStatsMember<T> not supporting enums, as well
> as the fact that in JavaScript enums are represented as basic strings,
> the stats enums have always been represented by T=std::string.
>
> Now that we have WebIDL-ified[1] all RTCStats dictionaries and enum
> values are simply string-copied (example: [2]) it seems safe to assume
> that "stats enums are just strings" is here to stay.
>
> Therefore there is little value in having C++ structs that look like
> enums so I'm deleting those in favor of std::string operator==()
> comparisons, e.g. `if (rtp_stream.kind == "audio")`. This removes some
> lines of code from our code base.
>
> I mostly want to get rid of these because they were taking up about 20%
> of the rtcstats_objects.h real estate...
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_stats_report.idl
> [2] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_stats_report.cc;l=667;drc=cf34e84c9df94256abfb1716ba075ed203975755
>
> Bug: webrtc:15245
> Change-Id: Iaf0827d7aecebc1cc02976a61663d5298d684f07
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308680
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#40295}
Bug: webrtc:15245
Change-Id: I05db80ba9f29460239de82cea9d95136e4c708e4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308860
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Christoffer Jansson <jansson@webrtc.org>
Owners-Override: Christoffer Jansson <jansson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40298}
Track stats are roughly equal in size as the RTP stream stats which
are the largest objects making up the majority of the RTCStatsReport
size and scales with meeting size. Deleting track/stream reduces the
size in approximately half which should reduce performance overhead
and unblock code simplifications.
Blocked on:
- https://chromium-review.googlesource.com/c/chromium/src/+/4517530
# Relevant bots already passed
NOTRY=True
Bug: webrtc:14175, webrtc:14419
Change-Id: Ib7bdb84c10459b42b829228d11876498e5227312
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/289043
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40129}
The web compat requirement that was the reason for keeping
is now solved in Chromium and its stats bindings.
BUG=webrtc:9674
Change-Id: Ifb722769414b2bcc5f4d36d7dff87a875336e039
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303860
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40024}
This reduces dependency on the struct RTCPReportBlock and would allow to
delete it in favor of class ReportBlockData
Bug: None
Change-Id: I93874c4f54cf62af0c16ae26e2231b8fb49f195d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304161
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39985}
* retransmittedBytesReceived
* retransmittedPacketsReceived
added to the specification in
https://github.com/w3c/webrtc-stats/pull/735
BUG=webrtc:15096
Change-Id: I6770e5d8d09ac1c2693c918fd943b0ab257ec7ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295260
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39959}
This reverts commit 7f16fcda0fd5bb625584b71311dd37b54c096136.
Reason for reland: Re-landing after addressing issues in downstream
code and hardening the ObserverAdapter from situations where attempted
usage of data channel proxies could occur after shutting down the
peer connection and terminating the network thread.
Original change's description:
> Revert "[DataChannel] Send and receive packets on the network thread."
>
> This reverts commit fe53fec24e02d2d644220f913c3f9ae596bbb2d9.
>
> Reason for revert: Speculative revert, may be breaking downstream project
>
> Original change's description:
> > [DataChannel] Send and receive packets on the network thread.
> >
> > This updates sctp channels, including work that happens between the
> > data channel controller and the transport, to run on the network
> > thread. Previously all network traffic related to data channels was
> > routed through the signaling thread before going to either the network
> > thread or the caller's thread (e.g. js thread in chrome). Now the
> > calls can go straight from the network thread to the JS thread with
> > enabling a special flag on the observer (see below) and similarly
> > calls to send data, involve 2 threads instead of 3.
> >
> > * Custom data channel observer adapter implementation that
> > maintains compatibility with existing observer implementations in
> > that notifications are delivered on the signaling thread.
> > The adapter can be explicitly disabled for implementations that
> > want to optimize the callback path and promise to not block the
> > network thread.
> > * Remove the signaling thread copy of data channels in the controller.
> > * Remove several PostTask operations that were needed to keep things
> > in sync (but the need has gone away).
> > * Update tests for the controller to consistently call
> > TeardownDataChannelTransport_n to match with production.
> > * Update stats collectors (current and legacy) to fetch the data
> > channel stats on the network thread where they're maintained.
> > * Remove the AsyncChannelCloseTeardown test since the async teardown
> > step has gone away.
> > * Remove `sid_s` in the channel code since we only need the network
> > state now.
> > * For the custom observer support (with and without data adapter) and
> > maintain compatibility with existing implementations, added a new
> > proxy macro that allows an implementation to selectively provide
> > its own implementation without being proxied. This is used for
> > registering/unregistering a data channel observer.
> > * Update the data channel proxy to map most methods to the network
> > thread, avoiding the interim jump to the signaling thread.
> > * Update a plethora of thread checkers from signaling to network.
> >
> > Bug: webrtc:11547
> > Change-Id: Ib4cff1482e31c46008e187189a79e967389bc518
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299142
> > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#39760}
>
> Bug: webrtc:11547
> Change-Id: Id0d65594bf727ccea5c49093c942b09714d101ad
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300341
> Auto-Submit: Andrey Logvin <landrey@webrtc.org>
> Owners-Override: Andrey Logvin <landrey@webrtc.org>
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39764}
Bug: webrtc:11547
Change-Id: I47dfa7e7168be0cd2faab4f8f3ebf110c3728af5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300360
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39786}
This reverts commit fe53fec24e02d2d644220f913c3f9ae596bbb2d9.
Reason for revert: Speculative revert, may be breaking downstream project
Original change's description:
> [DataChannel] Send and receive packets on the network thread.
>
> This updates sctp channels, including work that happens between the
> data channel controller and the transport, to run on the network
> thread. Previously all network traffic related to data channels was
> routed through the signaling thread before going to either the network
> thread or the caller's thread (e.g. js thread in chrome). Now the
> calls can go straight from the network thread to the JS thread with
> enabling a special flag on the observer (see below) and similarly
> calls to send data, involve 2 threads instead of 3.
>
> * Custom data channel observer adapter implementation that
> maintains compatibility with existing observer implementations in
> that notifications are delivered on the signaling thread.
> The adapter can be explicitly disabled for implementations that
> want to optimize the callback path and promise to not block the
> network thread.
> * Remove the signaling thread copy of data channels in the controller.
> * Remove several PostTask operations that were needed to keep things
> in sync (but the need has gone away).
> * Update tests for the controller to consistently call
> TeardownDataChannelTransport_n to match with production.
> * Update stats collectors (current and legacy) to fetch the data
> channel stats on the network thread where they're maintained.
> * Remove the AsyncChannelCloseTeardown test since the async teardown
> step has gone away.
> * Remove `sid_s` in the channel code since we only need the network
> state now.
> * For the custom observer support (with and without data adapter) and
> maintain compatibility with existing implementations, added a new
> proxy macro that allows an implementation to selectively provide
> its own implementation without being proxied. This is used for
> registering/unregistering a data channel observer.
> * Update the data channel proxy to map most methods to the network
> thread, avoiding the interim jump to the signaling thread.
> * Update a plethora of thread checkers from signaling to network.
>
> Bug: webrtc:11547
> Change-Id: Ib4cff1482e31c46008e187189a79e967389bc518
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299142
> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39760}
Bug: webrtc:11547
Change-Id: Id0d65594bf727ccea5c49093c942b09714d101ad
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300341
Auto-Submit: Andrey Logvin <landrey@webrtc.org>
Owners-Override: Andrey Logvin <landrey@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39764}
This updates sctp channels, including work that happens between the
data channel controller and the transport, to run on the network
thread. Previously all network traffic related to data channels was
routed through the signaling thread before going to either the network
thread or the caller's thread (e.g. js thread in chrome). Now the
calls can go straight from the network thread to the JS thread with
enabling a special flag on the observer (see below) and similarly
calls to send data, involve 2 threads instead of 3.
* Custom data channel observer adapter implementation that
maintains compatibility with existing observer implementations in
that notifications are delivered on the signaling thread.
The adapter can be explicitly disabled for implementations that
want to optimize the callback path and promise to not block the
network thread.
* Remove the signaling thread copy of data channels in the controller.
* Remove several PostTask operations that were needed to keep things
in sync (but the need has gone away).
* Update tests for the controller to consistently call
TeardownDataChannelTransport_n to match with production.
* Update stats collectors (current and legacy) to fetch the data
channel stats on the network thread where they're maintained.
* Remove the AsyncChannelCloseTeardown test since the async teardown
step has gone away.
* Remove `sid_s` in the channel code since we only need the network
state now.
* For the custom observer support (with and without data adapter) and
maintain compatibility with existing implementations, added a new
proxy macro that allows an implementation to selectively provide
its own implementation without being proxied. This is used for
registering/unregistering a data channel observer.
* Update the data channel proxy to map most methods to the network
thread, avoiding the interim jump to the signaling thread.
* Update a plethora of thread checkers from signaling to network.
Bug: webrtc:11547
Change-Id: Ib4cff1482e31c46008e187189a79e967389bc518
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299142
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39760}
* The pointer isn't needed for this notification. Arguably using
the internal id is more consistent with the stats code.
* Using the int makes it safer down the line to post the operation
from the network thread to the signaling thread rather than post
an object reference.
Bug: none
Change-Id: I1e9eb31d8386dca3feaa90ee3267ea98eb3e81ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299144
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39696}
to RTCInboundRtpStreamStats and RTCOutboundRtpStreamStats respectively
which follows the camel-casing convention used elsewhere.
The old name is kept around as an alias for a limited amount of time
to allow upgrading dependencies.
BUG=webrtc:14973
Change-Id: Ibf4e65933fd6cc2e7e89955042f6f8fb0f6c7853
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296261
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39497}
RTCStatsCollector internally keeps track of open data channels but
does not need (or want) to interact directly with those channels,
hence uintptr_t was used instead of pointers to the channel objects.
This changes that to use void* to avoid having to do the cast.
This is a follow-up action item to
https://webrtc-review.googlesource.com/c/src/+/295781
This CL also changes the container type:
std::set -> webrtc::flat_set
Bug: webrtc:12689
Change-Id: I13d3f4a41ef83dab38411193187e872b9d6d3cff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295871
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39468}
It turns out that there were several sigslot instances across data
channel, pc and stats classes that in practice only served as means
to update two counters in RTCStatsCollector. There's already a
notification path that's suitable.
This also fixes a case where the PC instance sat in the middle
of notifications from datachannels to the datachannel controller.
Bug: webrtc:11943
Change-Id: Ic60b76021584019f82085f6651230fe2fe82d465
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295781
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39456}