the foundation attribute is currently calculated as
CRC32(baseaddress, protocol, relayprotocol)
which is a way to satisfy the requirements from
https://www.rfc-editor.org/rfc/rfc5245#section-4.1.1.3
However, this leaks the base address which defeats the
MDNS obfuscation described in
https://datatracker.ietf.org/doc/draft-ietf-mmusic-mdns-ice-candidates/
since the CRC32 can be reversed using a table lookup as shown in
https://github.com/niespodd/webrtc-local-ip-leak/
To defeat that lookup, "seed" the CRC32 with the ICE tie-breaker which is a randomly picked unsigned 64 bit integer described in
https://www.rfc-editor.org/rfc/rfc5245#section-5.2
The tie-breaker is not known to Javascript and adding it scopes the foundation within the peer connection as described in section 4.1.1.3
To manually test (preferably with a DCHECK for IceTiebreaker() in ComputeFoundation)
- gather candidates twice on https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ and observe that the foundations are not the same after this change
- create two RTCPeerConnections with {iceCandidatePoolSize: 1}, create a datachannel, call setLocalDescription, inspect the candidates and observe that the foundations are not the same after this change.
Unit test changes have been split into a separate CL for easier integration.
BUG=webrtc:14605
Change-Id: I6bbad1635b48997b00ae74d251ae357bf8afd12f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280621
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38485}
This information is now readily available. Let's expose it.
In practise we don't pace audio by default and the delay is ~0, however
we can tell that this metric is working as intended by setting
PacingController's pace_audio_ to true via the "WebRTC-Pacer-BlockAudio"
field trial. In this case chrome://webrtc-internals/ plots neats graphs
for audio send delay.
Bug: webrtc:10635
Change-Id: Iecfd93bb84ec61e5d54232769a9e7a500601b199
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280523
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38483}
This metric was always supposed to be the spec's answer to
googBucketDelay, and is defined as "The total number of seconds that
packets have spent buffered locally before being transmitted onto the
network." But our implementation measured the time between capture and
send, including encode time. This is incorrect and yields a much larger
value than expected.
This CL updated the metric to do what the spec says. Implementation-wise
we measure the time between pushing and popping each packet from the
queue (in modules/pacing/prioritized_packet_queue.cc).
The spec says to increment the delay counter at the same time as we
increment the packet counter in order for the app to be able to do
"delta totalPacketSendDelay / delta packetSent". For this reason,
`total_packet_delay` is added to RtpPacketCounter. (Previously, the
two counters were incremented on different threads and observers.)
Running Google Meet on a good network, I could observe a 2-3 ms average
send delay per packet with this implementation compared to 20-30 ms
with the old implementation. See b/137014977#comment170 for comparison
with googBucketDelay which is a little bit different by design -
totalPacketSendDelay is clearly better than googBucketDelay.
Since none of this depend on the media kind, we can wire up this metric
for audio as well in a follow-up:
https://webrtc-review.googlesource.com/c/src/+/280523
Bug: webrtc:14593
Change-Id: If8fcd82fee74030d0923ee5df2c2aea2264600d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280443
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38480}
defined in
https://w3c.github.io/webrtc-encoded-transform/#rtcrtpsender-extension
Note: this does not implement the "rid(s)" parameter which will be done in a future CL.
VP8 still synchronizes keyframes on all layers even when asked for ones on individual layers while H264 (when implemented as three different encoders in SimulcastEncoderAdapter) can actually utilize this.
This does not change the behavior when receiving a RTCP PLI for a particular layer.
BUG=chromium:1354101
Change-Id: Ic8b14d155242e32c9aeafa55fe6652f346ac76b8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274169
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#38472}
This is exposing something that is already exposed in the legacy
getStats() API and is only available if the "video-timing" header
extension is used. Adding this metric here should unblock legacy
getStats() API deprecation. The follow-up to unship or standardize this
metric is tracked by https://crbug.com/webrtc/14586.
Bug: webrtc:14587
Change-Id: Ic3d45b0558d7caf4be2856a4cd95b88db312f85e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279860
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38444}
This includes the stats dictionaries that have been made obsolete in
the spec and whose IDs are prefixed "DEPRECATED_":
- RTCMediaStreamTrackStats
- RTCMediaStreamStats
There is an ongoing experiment to unship these stats dictionaries in
Chrome (https://crbug.com/1374215). Marking then as [[deprecated]] helps
alert other dependencies that these classes are deprecated.
In the meantime, the "DEPRECATED_RTCMediaStreamTrackStats" prefix makes
it possible to use the deprecated classes.
# Unrelated infra failures
NOTRY=True
Bug: webrtc:14175, webrtc:14419
Change-Id: I498d370294058a628278e1e5b027cd12e24ad31a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279700
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38439}
This patch adds variant of PeerConnectionInterface::AddTrack
that takes an initial_send_encodings.
This allows for setting/modifying encoding parameters before sdp
negotiation is performed/complete (e.g requested_resolution).
This is already available if using RtpTransciverInit and AddTransceiver,
but was not added to AddTrack because of concerns that it complicated matching with existing transceivers. This CL sidesteps that by never matching to a preexisting transceiver if initial_send_encodings are specified.
Note:
1) The patch adds a new method rather than an extra (e.g optional)
argument to existing AddTrack. This is to avoid problems with downstream mocks.
2) chromium "problems" was fixed in https://chromium-review.googlesource.com/c/chromium/src/+/3952684 and https://chromium-review.googlesource.com/c/chromium/src/+/3956060
Bug: webrtc:14451
Change-Id: I19b5a03872730280fbf868ca5d3a2f46443359f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278783
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38437}
Typically, remote candidates come from signalling and are deserialized
into C++ objects. The network_type field of these candidates is
always ADAPTER_TYPE_UNKNOWN.
However, in tests it is common to pass SDP and remote candidates as C++
objects. In this case, the network_type property of remote candidates
is preserved, so DCHECK might be triggered when GetStats is called.
Clearing fields that are not suitable as remote candidates fixes
this issue.
Bug: None
Change-Id: Ida01b0224bce5cf3e87bcad1ddaca35c9f4fffe7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279680
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38436}
ScalabilityMode should be validated against the currently
allowed codecs or the currently used codec.
Bug: webrtc:11607
Change-Id: Id2e6cbfad4f089de450150e1203657ed316e2f29
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277403
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38433}
which have shown that it is not easily possible to restrict
the pool size to 1 and combine this with max-bundle
BUG=webrtc:12383,chromium:1328218
Change-Id: I3a7ae4a263238c1b5faa079c3cbdaf84d1b40cbc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279141
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#38396}
This is a reland of commit c4b0bde7f2daabc4e0667fb73d096d1cf0819226
which changes the name of the new method and adds a deprecated
backward compatible variant with the old name.
Original change's description:
> ice server parsing: return RTCError with more details
>
> surfacing those errors to the API (without specific details) instead of just the logging.
>
> BUG=webrtc:14539
>
> Change-Id: Id907ebeb08b96b0e4225a016a37a12d58889091b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278340
> 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@{#38356}
Bug: webrtc:14539
Change-Id: I0a5482e123f25867582d62101b31ed207b95ea1a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278962
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38364}
This reverts commit c4b0bde7f2daabc4e0667fb73d096d1cf0819226.
Reason for revert: Breaks downstream tests.
Basically, ParseIceServers() and other functions have changed
the return type, and this breaks tests at compile time.
Is it possible to reland with backwards compatible versions that return
the previous type? Then they can be removed afterwards.
Original change's description:
> ice server parsing: return RTCError with more details
>
> surfacing those errors to the API (without specific details) instead of just the logging.
>
> BUG=webrtc:14539
>
> Change-Id: Id907ebeb08b96b0e4225a016a37a12d58889091b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278340
> 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@{#38356}
Bug: webrtc:14539
Change-Id: I4df936ff865f87759936c5d0425478fe51051dc8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278960
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#38359}
surfacing those errors to the API (without specific details) instead of just the logging.
BUG=webrtc:14539
Change-Id: Id907ebeb08b96b0e4225a016a37a12d58889091b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278340
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@{#38356}
which have shown that 32 is a reasonably safe limit and informed
https://github.com/w3c/webrtc-pc/pull/2679/
BUG=webrtc:13265,chromium:1360224
Change-Id: I63155653862e4c12720b8655c51ed5f3bdc742f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277804
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#38339}
This CL adds #includes to header files in order to make them
self contained after the preprocessor pass.
Bug: b/251890128
Change-Id: I81c3ba38fb8ab8a2bbd151ba99aa871fae9f1b1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278422
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38327}
They may be non-standard, but they shouldn't be on a stats dictionary
that is deprecated (track is going away soon-ish). By moving them to
inbound-rtp they can continue to exist beyond track deprecation and
live in the right place in case we decide to standardize them later.
To help downstream projects transitions, the metrics are temporarily
available in both old and new locations. Delete of old location will
happen in a follow-up CL. TODOs added.
Bug: webrtc:14524
Change-Id: I2008060fa4ba76cde859d9144d2bb9648c7ff9af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278200
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38315}
These metrics were recently standardized. Part of the standardization
effort was to move them from obsolete "track" stats (on track for
deprecation and removal: https://crbug.com/webrtc/14175) into the
"inbound-rtp" stats which are not deprecated.
To ease transition for downstream projects, the metrics are temporarily
duplicated in both the old and new locations. In a follow-up CL, they
will be deleted from "track".
Bug: webrtc:14521
Change-Id: I0d9036472607a8c717ec823a458a79a49ddb80c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278080
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38308}
Now that SDES is (largely) removed, this is no longer useful.
Bug: chromium:1365484
Change-Id: I3e626a7d5d83130a70958851de3df0aa27616bd2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277781
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38278}
`cached_certificates_by_transport_` is used on the network thread, but
can be cleared from the signaling thread. To fix the race where clear
happens at the same time as stats collecting, a mutex is added.
This mutex should very rarely be contended in practise since
ClearCachedStatsReport() typically only happen during renegotiation
(e.g. when someone joins/leaves) and getStats only happens once per
second or less (typically).
NOTRY=Everything passes except unrelated purple bot
Bug: webrtc:14510
Change-Id: Iaf539a5cc8c87184fa0a87b9c889a13b941a9ad1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277620
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38262}
Ability to emulate degraded networks using DegradedCall has not
been covered by tests and it is crashing due to DCHECKs.
Fix threading issues so this no longer crash.
Bug: None
Change-Id: I9276dfb1f71762faa02146af0bfaab713bebb7f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276060
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#38216}
According to a pprof, creating RTCCodecStats is one of the places where
we spend the most CPU time in the event of creating hundreds of them:
https://screenshot.googleplex.com/B6QNDvvoX8dK5vk
The lifetime was recently updated so that we no longer have to risk
creating hundreds of them, here is the relevant section:
https://w3c.github.io/webrtc-stats/#codec-dict*
This allows code simplifications and the deletion of
ProduceCodecStats_n since we can now do a lazy instantiation of codec
stats at the point of being referenced.
Bug: webrtc:14444
Change-Id: I342c5bfebe6a4be0359da3ea106692c7a217779e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275763
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38209}
Unlike the cache of the entire stats report which is time limited, this
certificate cache is valid for an unlimited amount of time, but is
cleared at ClearCachedStatsReport() which is already called on each
SLD/SRD call. Since certificates can only change by negotiation, this
cache is ensured to always be invalidated when certificates change.
Since ClearCachedStatsReport() can happen for other reasons than
certificates changing we may clear the cache more often then is
necessary, but arguably this is seldom enough that we don't have to
create a separate "ClearCertificateStats()" method. Keep it simple?
The cache specifically avoids rtc::SSLCertChain::GetStats which
trigger rtc::SSLCertificate::GetStats and rtc::Base64::EncodeFromArray.
Bug: webrtc:14458
Change-Id: I5f95a4a5eb51cc4462147270fdae7bb9fb7bc822
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276602
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38205}
In non-BUNDLE use cases, it is possible for multiple RTP streams to have
the same SSRC (as long as the SSRC is unique within the same transport).
This CL adds support for "outbound-rtp" and "inbound-rtp" stream stats
to have the same SSRC on different transports by adding the transport to
the stats ID. This avoids multiple RTP stream stats having the same
stats ID and fixes the problem. It's a stupid use case, but it should
work.
There could still be a stats ID collision in the event of multiple
"remote-inbound-rtp" or "remote-outbound-rtp" reference the same SSRC
but on separate transports for the same reason, and would require the
same fix... but one bug at a time. Not addressed in this CL.
Bug: webrtc:14443
Change-Id: I1a2ffd79fc67c2765e6dbd1ccc6828d4e91c4589
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275769
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38201}
To properly handle SSRC collisions in non-BUNDLE we need to change how
RTP stats IDs are generated, but that is a riskier change to be dealt
with in a separate CL.
For now, we just make sure that crashing is not a possibility during
SSRC collisions as a mitigation for https://crbug.com/1361612. This is
achieved by adding a TryAddStats() method to RTCStatsReport returning
whether successful.
Bug: chromium:1361612
Change-Id: I8577ae4c84a7c1eb3c7527e9efd8d1b0254269a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275766
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38197}
Creates the EmulatedSFUConfig that will receive the parameters for
controlling the virtual SFU used in the call.
Its current only field is the previous target_spatial_index from
VideoSimulcastConfig.
This allow to filter out the bottom layers for SVC S mode tests
and enable them.
Bug: webrtc:11607
Change-Id: Id4f3a96b3a03b9be7155796c3bafefce01f32b7d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274162
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38182}
The tests require H264 to be enabled using the proprietary_codecs
GN args.gn option.
Bug: webrtc:11607, webrtc:13961
Change-Id: I22dc3d94c844873ac12b9dce8e88a97f4fcf7657
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276046
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#38133}
Plan B having been deleted from Chrome, there is no need to collect UMAs
relating to Plan B vs Unified Plan setups.
Bug: chromium:1357994
Change-Id: Icb5d16823ea9d849798583cd1c82683014b8a15c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275309
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38069}
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}
apart from the certificate stats which need to update the
reference to the previous certificate stats in the chain.
BUG=None
Change-Id: I27f58084b849fd9afe236e5b57139bedb8eb1811
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274175
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38026}
The spec says: "Represents the total number of connectivity check
requests sent (not including retransmissions)."
I was surprised to find candidate-pair.requestsSent wired up to
`sent_ping_requests_before_first_response`, which is the subset of
`sent_ping_requests_total` that happened when `recv_ping_responses`
was 0. This is not what the spec says.
By wiring it up to `sent_ping_requests_total` instead, the modern
getStats implementation of "requestsSent" will match the legacy
getStats implementation which is already wired up to this value.
// Unrelated bot issues
NOTRY=True
Bug: webrtc:14425
Change-Id: Ia53c9711ee7a13e596ae0eacf6066b97d9a1face
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274174
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38025}
Ultimately, IDs should be random according to spec[1], so we shouldn't
rely on the ID to convey easily readable information. By making the IDs
shorter we reduce the overhead of string copies and make report dumps a
little bit smaller.
Drive-by: Add "DEPRECATED_" prefic to the RTCMediaStreamStats ID.
[1] https://w3c.github.io/webrtc-pc/#dom-rtcstats-id
# Examples of IDs before and after this CL #
RTCDataChannel_3
-> D3
RTCPeerConnection
-> P
RTCTransport_0_1
-> T01
RTCCodec_RTCTransport_0_1_100_minptime=10;useinbandfec=1
-> CIT01_100_minptime=10;useinbandfec=1
RTCInboundRTPAudioStream_6666
-> IA6666
RTCAudioSource_1
-> SA1
RTCOutboundRTPAudioStream_2943129392
-> OA2943129392
RTCRemoteInboundRtpAudioStream_3541280085
-> RIA3541280085
RTCIceCandidate_6cWRqicY
-> I6cWRqicY
RTCIceCandidatePair_6cWRqicY_haEcM2xD
-> CP6cWRqicY_haEcM2xD
RTCCertificate_FD1:BC:58:90:DF:E8:40:58:8D:04:91:44:93:4E:6C:52:9E:F0:14:98:AA:67:7B:8B:C8:30:C8:31:D0:84:1B:BF
-> CFD1:BC:58:90:DF:E8:40:58:8D:04:91:44:93:4E:6C:52:9E:F0:14:98:AA:67:7B:8B:C8:30:C8:31:D0:84:1B:BF
DEPRECATED_RTCMediaStreamTrack_receiver_3
-> DEPRECATED_TI3
RTCMediaStream_45a6e766-5d1a-40f9-a55c-ea8fdefcde49
-> DEPRECATED_S45a6e766-5d1a-40f9-a55c-ea8fdefcde49
Bug: webrtc:14416, webrtc:14419
Change-Id: I11f0a8b8354203fea1df1093d8864a6d47ee71e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273709
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37992}
The code incorrectly assumed that codecs exist on a per-mid/transceiver
basis, but codec payload types are unique on a per-transport basis and
in practise most applications use BUNDLE (single transport for the
entire PC).
This CL makes the codecs per-transport instead of per-transceiver. We
still need to iterate transceivers because codecs are exposed on a
per-transceiver basis and as shown in
https://jsfiddle.net/henbos/7kqxgnr8/ it is possible for FMTP lines to
be different on different m= sections despite BUNDLE.
Manual testing shows that this CL brings down the number of "codec"
stats in Google Meet 50p from 872 objects to 43 objects.
Bug: webrtc:14414
Change-Id: Ic854b31bd595799554b99fff22cbd48264ebd141
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273707
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Philipp Hancke <phancke@microsoft.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37989}
which may allow caching some relatively persistent statistics
such as codec statistics that only change during renegotiation.
BUG=webrtc:8693
Change-Id: Ifd68c9d666d9f328d0efecb64e4201d003788ca8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273324
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37981}
