We already cherry-picked this when we vendored 37458ce40a.
Upstream commit: https://webrtc.googlesource.com/src/+/054995011389d5adaf82804ea667d0727eb8002e
Revert "Per defaul probe max to 2x current BWE if max total allocated bitrate change"
This reverts commit 37458ce40a1741f9d5358d49fe49beed20140502.
Reason for revert: Will be wired up as an experiment instead.
Original change's description:
> Per defaul probe max to 2x current BWE if max total allocated bitrate change
>
> This aligns to probe limits in ALR for example.
>
> Bug: webrtc:369044000, b/369021234
> Change-Id: I3823b308cf97a8b7060b35b2ac38864e75d6f983
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363301
> Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
> Reviewed-by: Diep Bui <diepbp@webrtc.org>
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43074}
Bug: webrtc:369044000, b/369021234
Change-Id: I22b457254c9c21d2d951af2bda01a349ef83b3c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364242
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Ranveer Aggarwal <ranvr@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43130}
Upstream commit: https://webrtc.googlesource.com/src/+/00ff9dd4e4a0c9ae1e7ac2e2d5e91b92f1c0d336
Remove deprecated ParseIceServers variant
which has been deprecated since 2022 as shown by
git grep -n "\[\[deprecated" | while IFS=: read i j k; do git blame -L $j,$j $i -n -f | cat; done
BUG=webrtc:42224819
Change-Id: If7c5cc97aabfb43693ea3b07d45c3aa5ecc7236a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364181
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43129}
Upstream commit: https://webrtc.googlesource.com/src/+/b3ac753f26e2d41f718ab90ab18b244741ee2848
Iteratively fix unit tests to work with late assignment.
A number of unit tests assume that payload types will be assigned
without generating an offer. These are flushed out by running tests
with the --force_fieldtrials=WebRTC-PayloadTypesInTransport argument.
Bug: webrtc:360058654
Change-Id: I17cd5bfa275904a9630068190b1cd246e9ce8741
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362500
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43127}
When libwebrtc commit cf796a2d2c started using StrCat in rtc::ToString(),
Windows builds failed with a conflict StrCat and a Windows StrCatW symbol
defined in Shlwapi.h. Moving these 2 files to non-unified fixes the
issue:
desktop_capture_impl.cc
tab_capturer.cc
Differential Revision: https://phabricator.services.mozilla.com/D229833
Essentially a no-op since we're going to see this change
reverted when we vendor in 1fe80229cc.
Upstream commit: https://webrtc.googlesource.com/src/+/f88236066e65762f5543bf0ac141f23b76849126
Expose setHeaderExtensionsToNegotiate for iOS
Bug: webrtc:15766
Change-Id: I56ec97ab272c14b4b70f6c3d7a3daedde11738c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/336100
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
Auto-Submit: Karim Ham <karim@karhm.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43121}
We already cherry-picked this when we vendored f8b3dab7c6.
Upstream commit: https://webrtc.googlesource.com/src/+/084f1ae4bbc73de3880aaba3753adee0fbf3c6c2
Revert "Disable LibaomAv1Encoder tests to unblock Chromium roll"
This reverts commit f8b3dab7c6320a9890f0b003b43d7099e2e00a5b.
Reason for revert: The fix landed in libaom (https://aomedia-review.googlesource.com/c/aom/+/193761) and it is now available in WebRTC (import CL: https://webrtc-review.googlesource.com/c/src/+/364126).
Original change's description:
> Disable LibaomAv1Encoder tests to unblock Chromium roll
>
> The tests exercise the new encoder API that is not used in prod yet.
>
> Bug: webrtc:369633254
> Change-Id: Iee6bc16ebd471f4accdd9531cdb404f159557f51
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363820
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43083}
Bug: webrtc:369633254
Change-Id: Ia02db32f7f09e3abc3d0a46605feeabd82673f06
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364281
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#43120}
Upstream commit: https://webrtc.googlesource.com/src/+/949d3c9acf59af6bdcdf5152cac2df9cd5925cc3
Reland "h264: fix first_packet_in_frame logic for multislice in a single rtp packet"
This reverts commit bdc669347c70160cd648f5cab7a417227d41d82a.
Reason for revert: AUDs will be taken into account now.
video_replay with the provided out.pcap and these options:
--codec H264 --input_file out.pcap --media_payload_type 102 --ssrc 40000
plays smoothly.
Original change's description:
> Revert "h264: fix first_packet_in_frame logic for multislice in a single rtp packet"
>
> This reverts commit 3753c8190e3f0aca6758a5521e33f8b5d4f09ab4.
>
> Reason for revert: Break assembling of hardware encoded h264 P frame on
> weak network condition.
>
> Original change's description:
> > h264: fix first_packet_in_frame logic for multislice in a single rtp packet
> >
> > a frame must be (or should be) first when it contains either SPS (but not just PPS),
> > is an IDR or is a slice with first_mb_in_slice == 0.
> >
> > Fixes an edge case where a STAP-A with SPS, PPS and multiple slices of an IDR fit
> > into a single RTP packet which can happen with small 320x196 frames
> >
> > BUG=webrtc:352379280,webrtc:346608838
> >
> > Change-Id: Ic6dea6c81db759d0d7ddd4054407103fd791f6c5
> > No-Try: true
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357121
> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> > Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#42652}
>
> Bug: webrtc:368335257
> Change-Id: I07725c78be628bff71b79b8b9369677e39f5f5ac
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363080
> Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Philipp Hancke <phancke@meta.com>
> Cr-Commit-Position: refs/heads/main@{#43062}
Bug: webrtc:368335257
Change-Id: Idfae2efc1ebd7b97a2f7ebbd9d1e8c7bf6fcc348
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363842
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43113}
Upstream commit: https://webrtc.googlesource.com/src/+/d79a1859e058b6a030177b24ed8e4bb14525af79
ssl: increase default RSA key size to 2048 bits
since 1024 is already deprecated by OpenSSL and causes "too small key"
issues on systems enforcing a minimum size. Similar issue here:
https://github.com/nodejs/node/pull/44498
The minimum key size is not yet changed from 1024, this will require more effort for deprecation.
BUG=webrtc:364338811
Change-Id: Id4b24a2c289ec5e3f112288d32b8ac697ba1cfed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361128
Reviewed-by: David Benjamin <davidben@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43110}
We already cherry-picked this when we vendored 28b793b4dd.
Upstream commit: https://webrtc.googlesource.com/src/+/a6fbb35ac1849c5cd823ec90121d92fc5b776b35
Fix LibvpxVp9Encoder simulcast bug.
As of [1], a single VP9 encoder instance can produce simulcast 4:2:1.
When it does, the EncodedImage has its simulcast index set (0, 1, 2).
The bug is that if you then go back to a single encoder instance,
either because you're doing singlecast or because you're doing
simulcast with scaling factors that are not power of two (not 4:2:1),
then the simulcast index which was previously set to 2 is not reset due
to the old code path never calling SetSimulcastIndex.
Example repro:
1. Send VP9 simulcast {180p, 360p, 720p}, i.e. 4:2.1.
2. Reconfigure to {180p, 360p, 540p}, i.e. no longer 4:2:1.
What should happen: all three layers are sent.
What actually happened: 180p is not sent and the 540p layer flips flops
between 180p and 540p because the EncodedImage says simulcast index is
2 for both encodings[0] and encodings[2].
The fix is a one-line change: `SetSimulcastIndex(std::nullopt)` in the
case that we don't have a `simulcast_to_svc_converter_` that sets it
(0, 1, 2) for us.
[1] https://webrtc-review.googlesource.com/c/src/+/360280
Bug: chromium:370299916
Change-Id: I52bd4428bd12528f0e98869ec61626c06f589b43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363941
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43109}
Essentially a no-op since we're going to see this change
reverted when we vendor in 0a281e2c1a.
Upstream commit: https://webrtc.googlesource.com/src/+/0d3dcc499767166b32a941abc9563e259ce1770f
Delete AcmReceiver
The code now uses NetEq directly instead of AcmReceiver.
Bug: webrtc:14867
Change-Id: I11c7e2ca00060ab15bba5ec67dfd92ec413196f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364140
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43108}
Upstream commit: https://webrtc.googlesource.com/src/+/f5a547aa99a3697f9b9e7452f729ffb4411a29de
Make encrypted versions of RTP extension headers be stopped by default.
By this change we aim to remove the flag enable-webrtc-srtp-encrypted-headers.
Bug: chromium:40623740
Change-Id: I74692c90ff1caf2a11d7b73211c1ae4472edfb4d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362740
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43105}
Upstream commit: https://webrtc.googlesource.com/src/+/1831184330fbd14930a4fa393ce67722c0085070
Unify TLS cipher suite name handling
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}
Upstream commit: https://webrtc.googlesource.com/src/+/0a3a6908e820dbb002edfe97f176833e15217079
Ensure both corruption detection tests are formulated the same way
DoesNotPopulateFrameInstrumentationDataWhenSetNotTo should be formulated equivalently to PopulatesFrameInstrumentationDataWhenSetTo.
Bug: webrtc:358039777
Change-Id: I22d487d0a88cd3e1badb3bb8bf304a0322f9d53e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363862
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43090}
