This is a follow-up to:
https://webrtc-review.googlesource.com/c/src/+/318640
The problem was that the scoped field trials in the tests only
applied to the construction of the streams, not the handshake.
Note, although the changes are in OpenSSLStreamAdapter, this CL
actually fixes the SSLStreamAdapterTestDTLSExtensionPermutation tests
in rtc_base/ssl_stream_adapter_unittest.cc.
Bug: webrtc:15467
Change-Id: I25cdd758aab1bc67fd7a6a61c956c6d52f82e3d1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344762
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41976}
With this cl
RtpTransportControllerSend::OnAddPacket is instead directly invoked from PacketRouter::SendPacket instead of going via RTP module.
Transport sequence numbers are instead of directly written to header
extension, added to RtpPacketToSendMetaData and written to the extenion
by RTP module.
This is to allow transport sequence numbers without actually sending
them in an extension.
Bug: webrtc:15368
Change-Id: Idd03e02a4257dfc4d0f1898b2803345975d7dad2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344720
Reviewed-by: Erik Språng <sprang@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41974}
This reverts commit d427e83a15ad2950095ce1d352cc7e11eaf6cad3.
Reason for revert: Flaky test fixed.
Refactor FrameCandenceAdapter to keep track of input frame rate. This fixes an issue where frame rate is calculated too low if congestion window drop a frame.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887, webrtc:15893
Change-Id: I76268aa0991dbc99c1b881fb251a76aa54ff2673
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344561
Reviewed-by: Erik Språng <sprang@google.com>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41972}
The timeout was not long enough in debug mode on slower machines.
Bug: chromium:40072842
Change-Id: Id82399cd7211abf5dd2e03ffa2ee4bd49f8c492f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344680
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41971}
This reverts commit 784af1f42e89735587c442855fa01fc90475c449.
Reason for revert: Seems like test test_support_unittests
ResolutionAdaptsToAvailableBandwidth is flaky with this cl.
Original change's description:
> FrameCadenceAdapter keep track of Input framerate
>
> Refactor FrameCandenceAdapter to keep track of input frame rate.
>
> Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
> Uma is recorded to tell if input frame timestamp is monotonically increasing.
>
> Bug: webrtc:10481, webrtc:15887
> Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41967}
Bug: webrtc:10481, webrtc:15887
Change-Id: Id9672764768f2f40f8e711e990ad8ac18c28efcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344560
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41969}
Refactor FrameCandenceAdapter to keep track of input frame rate.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887
Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41967}
This reverts commit 802dd5bdbd97d880761059c7362c9e843211e32d.
First patch set is pure reland.
New patch set adds field trial flag.
Original change's description:
Stop exponential probing if 2xmax allocated bitrate lower than BWE.
Without this, if max allocated bitrate is lowered while exponential probing is ongoing, a new probe can be sent at a rate of the new low max allocated bitrate which may cause BWE to decrease.
Bug: webrtc:14928
Change-Id: I35c341bbaced800d9931657d62c73a17a3279b7c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344440
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41965}
When refactoring the WGC capture path, the check of a closed source
had been placed at a level where the notification of a closed source
was left without being detected since the error message was never
provided to the main WgcCapturerWin::CaptureFrame() which sends the
error message up to the client.
This trivial change ensures that WgcCapturerWin::CaptureFrame() returns
with DesktopCapturer::Result::ERROR_PERMANENT as soon as
WgcCaptureSession::OnItemClosed() has been triggered and it will
ensure that the WGC capture session stops and that any attached
MediaStreamTrack will signal its onended event as expected.
Bug: chromium:330863510
Change-Id: I57e44df417c33efa0595fc277cac5429cf539b26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344420
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41963}
After we're done sending all the messages, if the channel was in closing
state, then we start closing the association at the SCTP level, which
allows transitioning to the closed state.
Bug: chromium:40072842
Change-Id: I81b26b4137593b8feeb4bd9a2563cdfd67e1049e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344421
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41962}
The purpose is to be able to create a RtpPacketSendInfo from Pacing and RtpPacketSendInfo only.
This allow further refactoring where we directly in PacketRouter can notify BWE and early loss detection that a packet will be sent.
RtpPacketSendInfo::From is mostly added to be able to test conversion.
Bug: webrtc:15368
Change-Id: I5ebe2dc91d2eedf2c86e62c3f9738437082a49e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343766
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41961}
This reverts commit 5a4ce031019bce349ad65e76aa5da6d0f8e5989e.
Reason for revert: Breaks tests in downstream project.
Original change's description:
> Stop exponential probing if 2xmax allocated bitrate lower than BWE.
>
> Without this, if max allocated bitrate is lowered while exponential probing is ongoing, a new probe can be sent at a rate of the new low max allocated bitrate which may cause BWE to decrease.
>
> Bug: webrtc:14928
> Change-Id: Id8e314740c2403d3b801d28f634dbc718f77c16e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343384
> Reviewed-by: Diep Bui <diepbp@webrtc.org>
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41929}
Bug: webrtc:14928
Change-Id: I0d48b37bfb8684fd490f5685e510b438a83254b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343900
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41958}
This field trial will be used to roll out support for message
interleaving (RFC8260).
Bug: webrtc:5696
Change-Id: I5f91e8910ca5949fd62362a01e66f1e9bf834f81
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343765
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41955}
This reverts commit 7ae48c452abf8694a1b0a7a9a2aef13a9d10298a.
Reason for revert: breaks RtpVp9RefFinder
Original change's description:
> Mark frames with inter_layer_predicted=true as delta frames
>
> As it is currently implemented, the VP9 depacketizer decides packet's frame type based on p_bit ("Inter-picture predicted layer frame"). p_bit is set to 0 for upper spatial layer frames of keyframe since they do not have temporal refs. This results in marking packets of upper spatial layer frames, and, eventually these frames, of SVC keyframes as "keyframe" while they are in fact delta frames.
>
> Normally spatial layer frames are merged into a superframe and the superframe is passed to decoder. But passing individual layers to a single decoder instance is a valid scenario too and is used in downstream projects. In this case, an upper layer frame marked as keyframe may cause decoder reset [2] and break decoding.
>
> This CL changes frame type decision logic in the VP9 depacketizer such that only packets with both P and D (inter-layer predicted) bits unset are considered as keyframe packets.
>
> When spatial layer frames are merged into a superframe in CombineAndDeleteFrames [1], frame type of the superframe is inferred from the lowest spatial layer frame.
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/video_coding/frame_helpers.cc;l=53
>
> [2] https://source.corp.google.com/piper///depot/google3/third_party/webrtc/files/stable/webrtc/modules/video_coding/codecs/vp9/libvpx_vp9_decoder.cc;l=209
>
> Bug: webrtc:15827
> Change-Id: Idc3445636f0eae0192dac998876fedec48628560
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343342
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41939}
Bug: webrtc:15827
Change-Id: I697a057b8b3e88c07499f77c42f014da43cf1dc1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343763
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#41953}
After cl https://webrtc-review.googlesource.com/c/src/+/343122 there is
no default max frame rate.
Bug: webrtc:15885
Change-Id: Iac38895486d31bd267b578bbd1ab905dcdae00ff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344142
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41952}
The purpose of these new methods are to allow creating a RTP packet with
sequence numbers that
can be inspected and is ensured to be sent if SendPacket is invoked.
virtual bool CanSendPacket(const RtpPacketToSend& packet) const = 0;
virtual void AssignSequenceNumber(RtpPacketToSend& packet) = 0;
virtual void SendPacket(std::unique_ptr<RtpPacketToSend> packet,
const PacedPacketInfo& pacing_info) = 0;
Bug: webrtc:15368
Change-Id: I671e737575e15328e796aa98761a4d540c5812d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343785
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41951}
RtpPacketToSend::transport_sequence_number
packed_id is set to be 64 bit to align with rtc::PacketOptions.
packet_id is only set to RtpPacketToSend::transport_sequence_number if
TransportSequenceNumber header extension is not used in order to not
change current behaviour.
Bug: webrtc:15368
Change-Id: Ia532714226421422bdb292f8dd34b175560e9dc6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344160
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41950}
And move writing of the header extension from PacketRouter to
RtpSenderEgress::SendPacket.
Bug: webrtc:15368
Change-Id: Ieb18af4bc20115bf02d37e1f9a815a5c120975a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343786
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41949}
Start migrating away from `hasAudioLevel`, `voiceActivity`, `audioLevel` fields in RTPHeaderExtension and switch usages to a more modern absl::optional<AudioLevel> accessor instead.
The old fields are preserved for compatibility with downstream projects, but will be removed in the future.
Bug: webrtc:15788
Change-Id: I76599124fd68dd4d449f850df3b9814d6a002f5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/336303
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41947}
Try to increase the timeout to see if it solves the flakiness issue.
If it doesn't work we should temporary disable this test.
Change-Id: I8ecf3721cb5f7f4c647c8cbf247740c89c72ab82
Bug: webrtc:15885
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343982
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#41946}
This CL removes the send buffers (but not the receive buffer) from
SctpDataChannel and increases the send buffer in DcSctpSocket instead.
The reasons are:
1) Simplify the code. This additional buffering was strictly needed
before we migrated away from usrsctp, as that send buffer was very
limited in size (by design). But with the migration to dcSCTP, it's
no longer needed, so it just adds complexity.
2) Make `RTCDataChannel::bufferedAmount` correct. Before this CL, it
represented just the data buffered in SctpDataChannel, and not the
data accepted by the SCTP socket, but not yet put on the wire. This
makes it hard for clients to know when a message has ever been sent.
3) Better handle draining data on data channel close. While this is not
implemented in dcSCTP, having a single buffer makes this easier to
add.
While most of this CL is straightforward, the handling of bufferedAmount
in the signaling thread (in RTCDataChannel in Blink), is a bit special.
The number returned by `RTCDataChannel::bufferedAmount` is not what the
true value is inside the SCTP socket, but an eventual consistent view
of that value. When a message is sent, the value is incremented and:
- Before this change: When a message was put on the SCTP socket, the
view's value was decremented. Which made the view reflect what was
buffered outside the SCTP socket, and that buffering is now gone.
- After this change: SctpDataChannel will track what RTCDataChannel
will think it is, and provide updates to that number as we are
notified that it's reduced - by setting a "low threshold" callback
trigger.
A bonus with the new behavior is that it will be eventually consistent
and auto-heal also in error conditions - when messages are dropped due
to errors (bad input, bad state, etc). Previously, the bufferedAmount
value could drift away from the correct value on errors.
Note that a big chunk of unit tests were removed with this CL, as those
tested how the buffering behaved. Now, there is no buffering, so the
removed test cases represent a simpler interface.
This CL has been extensively tested with data channel benchmarks that
use the bufferedAmount thresholds (in Javascript).
Bug: chromium:40072842
Change-Id: I1a6a4af6b6e1116832f5028f989ce9f44683d229
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343361
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41945}
This code was extracted to make the next following CL easier to review.
This CL simply exposes the getters, setters and callbacks to set the
buffered amount low threshold on a specific SCTP stream. It will be
used in a follow-up CL, but is just boilerplate.
Bug: chromium:40072842
Change-Id: Iccd72208b369ddc252cc5886f6446b9c2ceeb0b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343360
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41943}
The parse error testcase creates a random byte string
and tries to parse it as a delta attribute expecting it to fail.
Ubsan detected that there was "unsafe" static_cast<>, where
a value from network is static_casted:ed into a enum.
That enum was then *checked* for validity, so I think it was
same before aswell.
This fix changes to do the check/convering as one step.
Bug: webrtc:15392
Change-Id: Ie2534deef8988bc3c3179e194155cfd48b0ee6e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343980
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41942}
This reverts commit c39712b51522bb21c18c58c593f454c5cc0e7995.
Reason for revert: Fixed issue where frame rate not adapted to highest "active" requested frame rate.
Patchset 1 contains original cl.
Later patchsets contains modifications.
Original change's description:
> Propagate known Encoder SinkWants when configured instead of after first frame.
>
> Propagate requested resolution and max frame rate to the source when
> configured rather than after the first frame.
> This is so that the source can be configured immediately. There is no
> reason why source should be updated until after first frame since it may lead
> to unnecessary reconfigurations and thread jumps. Wants that depend on actual frame size is not moved.
>
> Cl also change default behaviour in VideoStreamEncoderTest to not
> set restriction on max frame rate.
>
Bug: webrtc:14451
Change-Id: I2668db44bd17586efcf511ad3cd975065c503ec5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343122
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41941}
If SVC is used, the minimum bitrate would be 30kbps, instead of 49, as
configured in svc_config.h, because the overall stream will get min_bitrate
from the default VP8 simulcast configuration, and this 30kbps will be
allocated to the stream for svc_rate_allocator to divide between layers.
However, with the configuration before this change, 49kbps would be always
allocated to the lowest simulcast stream.
Bug: webrtc:15852
Change-Id: I1c77f45654af8850180a83f8e3f4428cc42d086e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343760
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41940}
As it is currently implemented, the VP9 depacketizer decides packet's frame type based on p_bit ("Inter-picture predicted layer frame"). p_bit is set to 0 for upper spatial layer frames of keyframe since they do not have temporal refs. This results in marking packets of upper spatial layer frames, and, eventually these frames, of SVC keyframes as "keyframe" while they are in fact delta frames.
Normally spatial layer frames are merged into a superframe and the superframe is passed to decoder. But passing individual layers to a single decoder instance is a valid scenario too and is used in downstream projects. In this case, an upper layer frame marked as keyframe may cause decoder reset [2] and break decoding.
This CL changes frame type decision logic in the VP9 depacketizer such that only packets with both P and D (inter-layer predicted) bits unset are considered as keyframe packets.
When spatial layer frames are merged into a superframe in CombineAndDeleteFrames [1], frame type of the superframe is inferred from the lowest spatial layer frame.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/video_coding/frame_helpers.cc;l=53
[2] https://source.corp.google.com/piper///depot/google3/third_party/webrtc/files/stable/webrtc/modules/video_coding/codecs/vp9/libvpx_vp9_decoder.cc;l=209
Bug: webrtc:15827
Change-Id: Idc3445636f0eae0192dac998876fedec48628560
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343342
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41939}
FFmpeg has removed this field and usage of it in chromium must be
removed before the ffmpeg dependency is updated. The chromium media
change can be found here:
https://chromium-review.googlesource.com/c/chromium/src/+/5384308
The usage of the field in webrtc seems only to be for sanity checking,
so it should be just safe to remove entirely, since webrtc does not
expect re-ordering at all.
Bug: chromium:330573128
Change-Id: I9c5854ec82c3ad2d55374ea4eaa0c571437f8267
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343840
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Ted (Chromium) Meyer <tmathmeyer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41935}
Without this, if max allocated bitrate is lowered while exponential probing is ongoing, a new probe can be sent at a rate of the new low max allocated bitrate which may cause BWE to decrease.
Bug: webrtc:14928
Change-Id: Id8e314740c2403d3b801d28f634dbc718f77c16e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343384
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41929}
