0 is not valid per https://tools.ietf.org/html/rfc5245#section-15.1 which says
<component-id>: is a positive integer between 1 and 256
This is part of the RTCIceTransport extension API which is probably going away.
BUG=chromium:1044875
Change-Id: I56d8dec79d3191e084f4a25a2c0a4d0b67afde74
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212642
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#33515}
This reverts commit 31c5c9da35209fe65ed15cb3a804823cd2789259.
Reason for revert: made QP parser thread-safe https://webrtc.googlesource.com/src/+/0e42cf703bd111fde235d06d08b02d3a7b02c727
Original change's description:
> Revert "Reland "Enable quality scaling when allowed""
>
> This reverts commit 0021fe77937f386e6021a5451e3b0d78d7950815.
>
> Reason for revert: Broken on linux_tsan bot: https://ci.chromium.org/ui/p/webrtc/builders/ci/Linux%20Tsan%20v2/25329/overview
>
> Original change's description:
> > Reland "Enable quality scaling when allowed"
> >
> > This reverts commit eb449a979bc561a8b256cca434e582f3889375e2.
> >
> > Reason for revert: Added QP parsing in https://webrtc.googlesource.com/src/+/8639673f0c098efc294a7593fa3bd98e28ab7508
> >
> > Original change's description:
> > Before this CL quality scaling was conditioned on scaling settings
> > provided by encoder. That should not be a requirement since encoder
> > may not be aware of quality scaling which is a WebRTC feature. In M90
> > chromium HW encoders do not provide scaling settings (chromium:1179020).
> > The default scaling settings provided by these encoders are not correct
> > (b/181537172).
> >
> > This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
> > is set to true in singlecast with normal video feed (not screen sharing)
> > mode. If quality scaling is allowed it is enabled no matter whether
> > scaling settings are present in encoder info or not. Setting from
> > QualityScalingExperiment are used in case if not provided by encoder.
> >
> > Bug: chromium:1179020
> > Bug: webrtc:12511
> > Change-Id: I97911fde9005ec25028a640a3f007d12f2bbc2e5
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211349
> > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33438}
>
> TBR=brandtr@webrtc.org,ilnik@webrtc.org,ssilkin@webrtc.org,rubber-stamper@appspot.gserviceaccount.com
>
> Change-Id: Id7633a1e98f95762e81487887f83a0c35f89195c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1179020
> Bug: webrtc:12511
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211352
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33439}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: I3a31e1c1fdf7da93226f8c1e0a96b43fe0b786df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212026
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33481}
Use PendingTaskSafetyFlag for safe Stop. Followup to
https://webrtc-review.googlesource.com/c/src/+/209181.
Also fix rtc::scoped_refptr to work with RTC_PT_GUARDED_BY.
Bug: webrtc:12339
Change-Id: Ic0e3ecb17049f1a0e6af887ba5f97a5b48a32d98
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211351
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33447}
This reverts commit 0021fe77937f386e6021a5451e3b0d78d7950815.
Reason for revert: Broken on linux_tsan bot: https://ci.chromium.org/ui/p/webrtc/builders/ci/Linux%20Tsan%20v2/25329/overview
Original change's description:
> Reland "Enable quality scaling when allowed"
>
> This reverts commit eb449a979bc561a8b256cca434e582f3889375e2.
>
> Reason for revert: Added QP parsing in https://webrtc.googlesource.com/src/+/8639673f0c098efc294a7593fa3bd98e28ab7508
>
> Original change's description:
> Before this CL quality scaling was conditioned on scaling settings
> provided by encoder. That should not be a requirement since encoder
> may not be aware of quality scaling which is a WebRTC feature. In M90
> chromium HW encoders do not provide scaling settings (chromium:1179020).
> The default scaling settings provided by these encoders are not correct
> (b/181537172).
>
> This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
> is set to true in singlecast with normal video feed (not screen sharing)
> mode. If quality scaling is allowed it is enabled no matter whether
> scaling settings are present in encoder info or not. Setting from
> QualityScalingExperiment are used in case if not provided by encoder.
>
> Bug: chromium:1179020
> Bug: webrtc:12511
> Change-Id: I97911fde9005ec25028a640a3f007d12f2bbc2e5
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211349
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33438}
TBR=brandtr@webrtc.org,ilnik@webrtc.org,ssilkin@webrtc.org,rubber-stamper@appspot.gserviceaccount.com
Change-Id: Id7633a1e98f95762e81487887f83a0c35f89195c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1179020
Bug: webrtc:12511
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211352
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33439}
This reverts commit eb449a979bc561a8b256cca434e582f3889375e2.
Reason for revert: Added QP parsing in https://webrtc.googlesource.com/src/+/8639673f0c098efc294a7593fa3bd98e28ab7508
Original change's description:
Before this CL quality scaling was conditioned on scaling settings
provided by encoder. That should not be a requirement since encoder
may not be aware of quality scaling which is a WebRTC feature. In M90
chromium HW encoders do not provide scaling settings (chromium:1179020).
The default scaling settings provided by these encoders are not correct
(b/181537172).
This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
is set to true in singlecast with normal video feed (not screen sharing)
mode. If quality scaling is allowed it is enabled no matter whether
scaling settings are present in encoder info or not. Setting from
QualityScalingExperiment are used in case if not provided by encoder.
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: I97911fde9005ec25028a640a3f007d12f2bbc2e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211349
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33438}
Spec: https://www.w3.org/TR/webrtc-stats/#receivedrtpstats-dict*
According to the spec, |RTCReceivedRtpStreamStats| is the base class for |RTCInboundRtpStreamStats| and |RTCRemoteInboundRtpStreamStats|. This structure isn't visible in JavaScript but it's important to bring it up to spec for the C++ part. This CL adds the barebone |RTCReceivedRtpStreamStats| with a bunch of TODOs for later migrations.
This commit makes the minimum |RTCReceivedRtpStreamStats| and rebase |RTCInboundRtpStreamStats| and |RTCRemoteInboundRtpStreamStats| to use the new class as the parent class.
This commit also moves |jitter| and |packets_lost| to |RTCReceivedRtpStreamStats|, from |RTCInboundRtpStreamStats| and |RTCRemoteInboundRtpStreamStats|. Moving these two first because they are the two that exist in both subclasses for now.
Bug: webrtc:12532
Change-Id: I0ec74fd241f16c1e1a6498b6baa621ca0489f279
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/210340
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/master@{#33435}
Spec: https://www.w3.org/TR/webrtc-stats/#dom-rtcvideosourcestats-frames
Wiring up the "frames" stats with the cumulative fps counter on the video source.
Tests:
./out/Default/peerconnection_unittests
./out/Default/video_engine_tests
Bug: webrtc:12499
Change-Id: I4103f56ed04cb464f5f7e70fbf2d77c25a867a68
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208782
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33404}
This reverts commit 83be84bb74133343358bba22e4e5106ecc385721.
Reason for revert: Suspect of crbug.com/1185276
Original change's description:
> Reland "Enable quality scaling when allowed"
>
> This reverts commit 609b524dd3ff36719b5c4470b85d37dcdadfb1f8.
>
> Reason for revert: Disable QualityScalingAllowed_QualityScalingEnabled on iOS.
>
> Original change's description:
> Before this CL quality scaling was conditioned on scaling settings
> provided by encoder. That should not be a requirement since encoder
> may not be aware of quality scaling which is a WebRTC feature. In M90
> chromium HW encoders do not provide scaling settings (chromium:1179020).
> The default scaling settings provided by these encoders are not correct
> (b/181537172).
>
> This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
> is set to true in singlecast with normal video feed (not screen sharing)
> mode. If quality scaling is allowed it is enabled no matter whether
> scaling settings are present in encoder info or not. Setting from
> QualityScalingExperiment are used in case if not provided by encoder.
>
> Bug: chromium:1179020
> Bug: webrtc:12511
> Change-Id: Ia0923e5a62acdfdeb06f9aad5d670be8a0f8d746
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209643
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33385}
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: I7004014c5936176f8c125aeb55da91ce095b266e
TBR: ssilkin@webrtc.org
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209708
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33393}
This reverts commit 609b524dd3ff36719b5c4470b85d37dcdadfb1f8.
Reason for revert: Disable QualityScalingAllowed_QualityScalingEnabled on iOS.
Original change's description:
Before this CL quality scaling was conditioned on scaling settings
provided by encoder. That should not be a requirement since encoder
may not be aware of quality scaling which is a WebRTC feature. In M90
chromium HW encoders do not provide scaling settings (chromium:1179020).
The default scaling settings provided by these encoders are not correct
(b/181537172).
This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
is set to true in singlecast with normal video feed (not screen sharing)
mode. If quality scaling is allowed it is enabled no matter whether
scaling settings are present in encoder info or not. Setting from
QualityScalingExperiment are used in case if not provided by encoder.
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: Ia0923e5a62acdfdeb06f9aad5d670be8a0f8d746
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209643
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33385}
This reverts commit 752cbaba907de077e5f1b24a232e71feb479dccb.
Reason for revert: The test VideoStreamEncoderTest.QualityScalingAllowed_QualityScalingEnabled seems to fail on iOS.
Original change's description:
> Enable quality scaling when allowed
>
> Before this CL quality scaling was conditioned on scaling settings
> provided by encoder. That should not be a requirement since encoder
> may not be aware of quality scaling which is a WebRTC feature. In M90
> chromium HW encoders do not provide scaling settings (chromium:1179020).
> The default scaling settings provided by these encoders are not correct
> (b/181537172).
>
> This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
> is set to true in singlecast with normal video feed (not screen sharing)
> mode. If quality scaling is allowed it is enabled no matter whether
> scaling settings are present in encoder info or not. Setting from
> QualityScalingExperiment are used in case if not provided by encoder.
>
> Bug: chromium:1179020, webrtc:12511
> Change-Id: I83d55319ce4b9f4fb143187ced94a16a778b4de3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209184
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33373}
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: Icabf2d9a034d359f79491f2c37f1044f17a7445d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209641
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33381}
Before this CL quality scaling was conditioned on scaling settings
provided by encoder. That should not be a requirement since encoder
may not be aware of quality scaling which is a WebRTC feature. In M90
chromium HW encoders do not provide scaling settings (chromium:1179020).
The default scaling settings provided by these encoders are not correct
(b/181537172).
This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
is set to true in singlecast with normal video feed (not screen sharing)
mode. If quality scaling is allowed it is enabled no matter whether
scaling settings are present in encoder info or not. Setting from
QualityScalingExperiment are used in case if not provided by encoder.
Bug: chromium:1179020, webrtc:12511
Change-Id: I83d55319ce4b9f4fb143187ced94a16a778b4de3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209184
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33373}
The new verification makes verification a function on a message.
It also stores the password used in the request message, so that
it is easily accessible when verifying the response.
Bug: chromium:1177125
Change-Id: I505df4b54214643a28a6b292c4e2262b9d97b097
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209060
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33366}
Tests:
./out/Default/peerconnection_unittests
Manually tested with Chromium to see the data populated
Spec: https://w3c.github.io/webrtc-stats/#remoteinboundrtpstats-dict*
Bug: webrtc:12506
Change-Id: I60ef8061fb31deab06ca5f115246ceb5a8cdc5ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208960
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33361}
This is a reland of a37f2bd9421868e222d591d3371486a6ab939fd6
Original change's description:
> Rename SIGNALING and WORKER to PRIMARY and SECONDARY
>
> This makes the proxy macros less confusing when the secondary thread
> is sometimes the worker thread, sometimes the networking thread.
>
> Bug: none
> Change-Id: I1a8cebb82d09be44fe40e80c861bcfb47b9928e8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208763
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33346}
Bug: none
Change-Id: If46a6679ac0fc947797dd7be87626ef7702faca2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208845
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33349}
This reverts commit a37f2bd9421868e222d591d3371486a6ab939fd6.
Reason for revert: Breaks compile step (e.g. https://ci.chromium.org/ui/p/webrtc/builders/ci/Android64%20Builder%20x64%20(dbg)/19773/overview).
Original change's description:
> Rename SIGNALING and WORKER to PRIMARY and SECONDARY
>
> This makes the proxy macros less confusing when the secondary thread
> is sometimes the worker thread, sometimes the networking thread.
>
> Bug: none
> Change-Id: I1a8cebb82d09be44fe40e80c861bcfb47b9928e8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208763
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33346}
TBR=hta@webrtc.org
Bug: none
Change-Id: I2014faab3392f445f56edd9e833d00000ebc5ca3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208840
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33347}
This makes the proxy macros less confusing when the secondary thread
is sometimes the worker thread, sometimes the networking thread.
Bug: none
Change-Id: I1a8cebb82d09be44fe40e80c861bcfb47b9928e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208763
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33346}
This will allow us to optimize the internal buffers of
webrtc::VideoFrame for the resolution(s) that we actually want to
encode.
Bug: webrtc:12469, chromium:1157072
Change-Id: If378b52b5e35aa9a9800c1f7dfe189437ce43253
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208540
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33342}
Trying to take my first stab at contributing to WebRTC and I chose to populate jitter stats for video RTP streams. Please yell at me if this isn't something I'm not supposed to pick up. Appreciate a review, thanks!
Bug: webrtc:12487
Change-Id: Ifda985e9e20b1d87e4a7268f34ef2e45b1cbefa3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208360
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/master@{#33325}
Currently the echo canceller reference signal is high-pass filtered to
avoid the need of modeling the capture-side high-pass filter as part of
the echo path.
This can lead to the lowest frequency bins of the linear filter
diverging as there is little low-frequency content available for
training. Over time the filter can output an increasing amount of
low-frequency power, which in turn affects the filter's ability to
adapt properly.
Disabling the high-pass filtering of the echo canceller reference solves
this issue, resulting in improved filter convergence.
Bug: webrtc:12265
Change-Id: Ic526a4b1b73e1808cfcd96a8cdee801b96a27671
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208288
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33322}
This remove webrtc-specific macro that has no reason to be webrtc specific
ABSL_DEPRECATED takes a message parameter encouraging to write text how class or function is deprecated.
Bug: webrtc:12484
Change-Id: I89f1398f91dacadc37f7db469dcd985e3724e444
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208282
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33314}
This make it easier to create parameters from a single endpoint ptr.
Bug: None
Change-Id: Id64757353505a21c7731655e1b7a3178fa2e5ef8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/207425
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33263}
Audio interruption metric is not implemented for codecs doing their own PLC.
R=ivoc@webrtc.org, jakobi@webrtc.org
Bug: b/177523033 webrtc:12456
Change-Id: I0aca6fa5c0ff617e76ee1e4ed8d95703c7097223
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206561
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Pablo Barrera González <barrerap@google.com>
Cr-Commit-Position: refs/heads/master@{#33229}
This reverts commit 6b143c1c0686519bc9d73223c1350cee286c8d78.
Reason for revert:
Relanding with updated expectations for SctpTransport::Information
based on TransceiverStateSurfacer in Chromium.
Original change's description:
> Revert "Fix unsynchronized access to mid_to_transport_ in JsepTransportController"
>
> This reverts commit 6cd405850467683cf10d05028ea0f644a68a91a4.
>
> Reason for revert: Breaks WebRTC Chromium FYI Bots
>
> First failure:
> https://ci.chromium.org/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20Android%20Tests%20%28dbg%29%20%28L%20Nexus5%29/1925
>
> Failed tests:
> WebRtcDataBrowserTest.CallWithSctpDataAndMedia
> WebRtcDataBrowserTest.CallWithSctpDataOnly
>
> Original change's description:
> > Fix unsynchronized access to mid_to_transport_ in JsepTransportController
> >
> > * Added several thread checks to JTC to help with programmer errors.
> > * Avoid a few Invokes() to the network thread here and there such
> > as for fetching sctp transport name for getStats(). The transport
> > name is now cached when it changes on the network thread.
> > * JsepTransportController instances now get deleted on the network
> > thread rather than on the signaling thread + issuing an Invoke()
> > in the dtor.
> > * Moved some thread hops from JTC over to PC which is where the problem
> > exists and also (imho) makes it easier to see where hops happen in
> > the PC code.
> > * The sctp transport is now started asynchronously when we push down the
> > media description.
> > * PeerConnection proxy calls GetSctpTransport directly on the network
> > thread instead of to the signaling thread + blocking on the network
> > thread.
> > * The above changes simplified things for webrtc::SctpTransport which
> > allowed for removing locking from that class and delete some code.
> >
> > Bug: webrtc:9987, webrtc:12445
> > Change-Id: Ic89a9426e314e1b93c81751d4f732f05fa448fbc
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205620
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33191}
>
> TBR=tommi@webrtc.org,hta@webrtc.org
>
> Change-Id: I7b2913d5133807589461105cf07eff3e9bb7157e
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:9987
> Bug: webrtc:12445
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206466
> Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
> Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33204}
TBR=tommi@webrtc.org,hta@webrtc.org,guidou@webrtc.org
# Not skipping CQ checks because this is a reland.
Bug: webrtc:9987
Bug: webrtc:12445
Change-Id: Icb205cbac493ed3b881d71ea3af4fb9018701bf4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206560
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33219}
measured in the connectionstatechange event to connected which usually
happens once per connection.
BUG=webrtc:12383
Change-Id: Ida136c44bfe65e922627390747f8bee384603715
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204301
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Justin Uberti <juberti@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#33207}
This reverts commit 6cd405850467683cf10d05028ea0f644a68a91a4.
Reason for revert: Breaks WebRTC Chromium FYI Bots
First failure:
https://ci.chromium.org/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20Android%20Tests%20%28dbg%29%20%28L%20Nexus5%29/1925
Failed tests:
WebRtcDataBrowserTest.CallWithSctpDataAndMedia
WebRtcDataBrowserTest.CallWithSctpDataOnly
Original change's description:
> Fix unsynchronized access to mid_to_transport_ in JsepTransportController
>
> * Added several thread checks to JTC to help with programmer errors.
> * Avoid a few Invokes() to the network thread here and there such
> as for fetching sctp transport name for getStats(). The transport
> name is now cached when it changes on the network thread.
> * JsepTransportController instances now get deleted on the network
> thread rather than on the signaling thread + issuing an Invoke()
> in the dtor.
> * Moved some thread hops from JTC over to PC which is where the problem
> exists and also (imho) makes it easier to see where hops happen in
> the PC code.
> * The sctp transport is now started asynchronously when we push down the
> media description.
> * PeerConnection proxy calls GetSctpTransport directly on the network
> thread instead of to the signaling thread + blocking on the network
> thread.
> * The above changes simplified things for webrtc::SctpTransport which
> allowed for removing locking from that class and delete some code.
>
> Bug: webrtc:9987, webrtc:12445
> Change-Id: Ic89a9426e314e1b93c81751d4f732f05fa448fbc
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205620
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33191}
TBR=tommi@webrtc.org,hta@webrtc.org
Change-Id: I7b2913d5133807589461105cf07eff3e9bb7157e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9987
Bug: webrtc:12445
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206466
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33204}
* Added several thread checks to JTC to help with programmer errors.
* Avoid a few Invokes() to the network thread here and there such
as for fetching sctp transport name for getStats(). The transport
name is now cached when it changes on the network thread.
* JsepTransportController instances now get deleted on the network
thread rather than on the signaling thread + issuing an Invoke()
in the dtor.
* Moved some thread hops from JTC over to PC which is where the problem
exists and also (imho) makes it easier to see where hops happen in
the PC code.
* The sctp transport is now started asynchronously when we push down the
media description.
* PeerConnection proxy calls GetSctpTransport directly on the network
thread instead of to the signaling thread + blocking on the network
thread.
* The above changes simplified things for webrtc::SctpTransport which
allowed for removing locking from that class and delete some code.
Bug: webrtc:9987, webrtc:12445
Change-Id: Ic89a9426e314e1b93c81751d4f732f05fa448fbc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205620
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33191}
We need to be able build chromium with rtc_include_tests = true. It
reveals a lot of targets that are not compatible with chromium but
aren't marked so.
`rtc_include_tests=true` has been considered a way to disable targets for the Chromium build, causing an overload on rtc_include_tests while the meaning of the two GN args (rtc_include_tests and build_with_chromium) should be kept separated.
Bug: webrtc:12404
Change-Id: I2f72825445916eae7c20ef9338672d6a07a9b9ff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/203890
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33124}
adds metrics for bundle usage, differentiating between
* BUNDLE is not negotiated and there is only a datachannel,
* BUNDLE is not negotiated and there is at most one m-line per media type,
for unified-plan
* BUNDLE is not negotiated and there are multiple m-lines per media type,
* BUNDLE is negotiated and there is only a datachannel,
* BUNDLE is negotiated but there is at most one m-line per media type,
* BUNDLE is negotiated and there are multiple m-lines per media type,
and for plan-b
* BUNDLE is negotiated
* BUNDLE is not negotiated
BUG=webrtc:12383
Change-Id: I41afc4b08fd97239f3b16a8638d9753c69b46d22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202254
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33090}
