This stores usage for all cases, making it easier to discover
abusive usages on unexpected patterns.
Bug: None
Change-Id: I62c9b07498e811ac04c221f57cfbc02312aaaacc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368902
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43442}
- Add `WebRTC-Audio-OpusDecodeStereoByDefault` field trial
- Behind that field trial, `AudioDecoderOpus::SdpToConfig` uses 2
instead of 1 as default number of channels when the `stereo` codec
param is unspecified
- Instead of wiring up `FieldTrialsView` to `SdpToConfig`, which
requires API changes that break downstream projects, a change in
`AudioDecoderOpus::Config` is made to signal when the number of
channels is forced via SDP config
Bug: webrtc:379996136
Change-Id: If70eb19bc7e3bc74dd0423610cb04ae33ea602fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368860
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43440}
Too big median window will cause errors with large clock drifts, since we'll end up using old values for estimated clock drift.
If the window is too small, the remote clock offset estimation could be noisy or we could even end up using outliers as the offset estimation.
I will not claim that I choose the correct value, and I'm not sure how to measure the quality of the remote clock offset estimations.
Bug: webrtc:379809147
Change-Id: Ib317548d3eec74105d468ef53830e12eb114df7d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368580
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Cr-Commit-Position: refs/heads/main@{#43439}
The clock rate is already known by the RTP statistician.
Also included some minor code cleanup.
Bug: b/331602608
Change-Id: I335fa2a1cfd7dcceb286706d295a175a92f6797c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368920
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43436}
According to latest requirement, when the level reported by
RtpSender.getCapabilities() for H.265 is different from that was
negotiated, we should not throw when setParameters() is called with
level-id set to that reported by RtpSender.getCapabilities().
Underlingly negotiated codec level should remain unchanged.
Bug: chromium:41480904
Change-Id: I28bbdb5f0a0ab0d98315f56c80004601afc91a63
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368781
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/main@{#43434}
In particular, some platforms have a limited pool of frames in the
capturer stack, so we need to avoid stashing raw frames in the frame
instrumentation generator that may be dropped by limiting the size of
the queue and avoid putting anything in there until we know we will
send it to the encoder.
Bug: webrtc:358039777
Change-Id: I054ae53dd5e6ac6a22da39c5049f47788561e77a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368641
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43432}
Also CHECK in OutputPathWithRandomDirectory. This function is used in tests that need a unique folder to avoid interaction with other tests that may run in parallel. Continuing with a non-unique folder if the creation fails, is likely to cause surprising errors later on.
Bug: webrtc:379973428
Change-Id: I6a30ef9034be8132e2362eff5e46e3b99b30acd2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368542
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43431}
This is preparatory to ensuring that transport-cc gets turned off when
RFC8888 ccfb is negotiated.
Bug: webrtc:378698658
Change-Id: Ie76677bd6aa046701562bbd93d8489858488f863
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368543
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43426}
On a sendrecv m-line, the offered level-id represents the maximum that
can be both sent and received; on a sendonly m-line, the offered
level-id represents the maximum that can be sent; on a recvonly m-line,
the offered level-id represents the maximum that can be received.
Also according to RFC 7798 section 5, the highest level indicated by the
answer is either equal to or lower than that in the offer
Bug: chromium:41480904
Change-Id: I1729c8edc3aed0c00c41cea96204abafc37c002b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367322
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43425}
This updates test code that tests interleaved audio frames to use
some of the same properties and types as AudioFrame (rather than copy).
The CL also moves code from audio_processing_unittest.cc that modifies
the buffer owned by Int16FrameData, into Int16FrameData.
Bug: none
Change-Id: Iab37227deb302bf4fc832633d312262e5249caad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355960
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43424}
When receiving streams with frame rates around 1 fps, the decode and
render fps were incorrectly reported as 0, even though frames were being
decoded successfully.
This commit addresses the issue by adjusting the calculation in
RateStatistics to better handle streams with frame intervals that are
close to the window size.
1 fps streams are an important special case that occur frequently in
in screen share scenarios.
Fixed: webrtc:354625675
Change-Id: I1362768229a3abab5929220ba4bbd5ccb06a33d2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368080
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43417}
TimestampExtrapolator maps RTP timestamps of received video frames
to local timestamps. As part of this mapping, the clock drift
between the local and remote clock is estimated.
Add the histogram WebRTC.Video.EstimatedClockDrift_ppm to log the
relative clock drift in points per million.
Bug: b/363166487
Change-Id: I0c2e628ef72c05a93e1f3138c8f71c77467130b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368342
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43413}
This is a reland of commit 775639e930f14a619974944594b40c633cc574a3
Original change's description:
> Set default scalability mode for H.265 to L1T1.
>
> H.265 does not have software fallback, and it may have issue supporting
> more than 1 temporal layers on some devices. Set default to L1T1 when
> scalability is not configured, or if a scalability mode is reported as
> not supported by encoder.
>
> Bug: chromium:41480904
> Change-Id: I53895c45ec821d65774ffe2db5f418184e3fb02a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367835
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Cr-Commit-Position: refs/heads/main@{#43389}
Bug: chromium:41480904
Change-Id: Idedf6249130bd01dd31261672c624b88c3f4c1de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368261
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43412}
This seems to have no effect on tests, so it appears that these were
not used after all.
The goal is to make transport-cc a media-section-level attribute.
Bug: webrtc:378698658
Change-Id: Ia20ca5b91472b02db30f911ad1a1892cf36cd682
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368440
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43411}
Instead use the preprocessor to avoid compiling Perfetto related code
when RTC_USE_PERFETTO is not defined.
Bug: None
Change-Id: I85b37cb0287327035ac2e8feb3caf9505486a1e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368343
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43410}
stun_prober will fail on Windows and return RESOLVE_FAILED
Bug: webrtc:378688998
Change-Id: I3b957f6b2adf6658a0f6b83c8ff427ffd9779f8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368140
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43405}
H.265 should have limits probably between VP9 and AV1, instead of using
VP8 tables. For now we reuse VP9 tables but eventually we may create
table for H.265.
Bug: chromium:41480904
Change-Id: I6dc2ec629142ee06f1c82a2df30d753ec1353496
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368240
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43404}
The gn target for rtc_pc_unittests cleared the "configs" that is by
default set for rtc_test. Restore it back so we get RTC_ENABLE_H265
macro when rtc_use_h265 is configured.
BUG: chromium:41480904
Change-Id: If172482776e5be2ad99d976db12dcfa556ee8a24
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368183
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43403}
which is already gone from the code.
BUG=webrtc:40644300
Change-Id: Ic4a53d7895fa49d8417f11778d128740cecaee49
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368180
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43401}
Dependency is required for Chromium roll in WebRTC.
Change-Id: I284c55f97bae3eee638d7a9f9fb5319fa1ae24e8
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368021
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43399}
This will turn on RFC 8888 feedback messages if "ack ccfb" is negotiated.
This should eliminate the need for the "force" flag in the field trial.
Bug: webrtc:42225697
Change-Id: Iec7a894c244a417a8499200861550a33f89966a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367400
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43398}
This reverts commit 775639e930f14a619974944594b40c633cc574a3.
Reason for revert: Breaks internal tests.
Original change's description:
> Set default scalability mode for H.265 to L1T1.
>
> H.265 does not have software fallback, and it may have issue supporting
> more than 1 temporal layers on some devices. Set default to L1T1 when
> scalability is not configured, or if a scalability mode is reported as
> not supported by encoder.
>
> Bug: chromium:41480904
> Change-Id: I53895c45ec821d65774ffe2db5f418184e3fb02a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367835
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Cr-Commit-Position: refs/heads/main@{#43389}
Bug: chromium:41480904
No-Try: true
Change-Id: I5485b1abfd5f586ec187cc57817940aa2efd72af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368200
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43396}
The workaround in https://webrtc-review.googlesource.com/c/src/+/367740
is incomplete because it does not fix the issue for the first decoded
mono packet after CN/PLC. This CL extends the workaround to such a case
and adds a unit test for it.
Note: it was verified that the 2nd packet after CN/PLC is trivial
stereo.
Credits: jakobi@webrtc.org for raising the concern
Bug: webrtc:376493209
Change-Id: Ide27e411781693f14629cf9db8b6c0c0fc762a17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368160
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43393}
