This hard-codes the behavior to mode 3 with a threshold of 0.5 like was
already done by FetchPreEchoConfiguration.
Bug: webrtc:14205
Change-Id: I48d47a77c9df0001460788b504524203417f9647
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345483
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42015}
This CL partly restores the changes that were introduced in
https://webrtc-review.googlesource.com/c/src/+/344681
The predefined SdpVideoFormat for AV1 causes some backwards
compatibility issues with downstream projects that are using
the preliminary codec name AV1X.
Bug: b/333007070
Change-Id: I2d4df241d47b399b0012e6095dd6c2445e60e2c1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345941
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42011}
This changes the libvpx VP9 encoder to generate the scalability mode based on the current encoding parameters when using layer activation.
Tested: Ran with L3T3_KEY reduced to L2T3_KEY and L1T3 due to bandwidth or layer activation. Added unit tests.
Bug: webrtc:15892
Change-Id: Iaedca4ea5fc3a692996666ceaf0d6aa03fb058a1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344760
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42007}
With a previous refactoring, which made the data tracker responsible for
ensuring that the reassembly queue doesn't see any duplicate received
chunks, it no longer needs to know the initial peer's TSN. Removing.
Bug: None
Change-Id: I0e2aef1de0293f1860b46dee0089757c9c300aea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345701
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41997}
While an empty realm attribute is technically allowed, it reduces
the amount of entropy that goes into the turn credentials hash.
This remains technically broken in the implementation as hash_ is
not recomputed when changing the realm from the initial empty string
value to the empty string. Before this change this lead to hash_ not
being set and the allocate request being treated as not having
enough details to authenticate, resulting in an endless loop of packets.
BUG=chromium:329978076
Change-Id: I3d1295f905a9fb58ca5bc6f82466896f79031865
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344820
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Christoffer Dewerin <jansson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41996}
This code was moved to ReassemblyQueue::AddReassembledMessage, the build
file was updated to remove the source file, but the source file was
never actually deleted. Dead code.
Bug: None
Change-Id: Iafb9bb276ff870398a76737ceb16ffc50a91738e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345620
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41994}
The predefined SdpVideoFormats were not used everywhere,
which caused a discrepancy between send/receive capabilities
for AV1. This CL solves the immediate problems by making sure
send/receive capabilities for AV1 are reported the same way.
Fixed: chromium:331565934
Change-Id: I073091b7b5f987c7f434c17276fd84047ec723c2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344681
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41991}
This code looked a bit weird before this CL - probably because of old
refactorings.
In JsepTransport constructor, there is a DCHECK assuring that the RTP
DTLS transport is always present, so it can be passed directly to the
SctpTransport constructor, which avoids having the SetDtlsTransport
method in it.
Also, in the SctpTransport constructor, there was code that would set
the SCTP transport state to `kConnecting` if the DTLS transport was
present, but that was dead code, as it was always `nullptr` inside the
constructor before this CL. With this CL, it's always present, and the
SCTP Transport's state will initially always be `kConnecting` now. Which
is a step to deprecating the `kNew` state that doesn't exist in
https://w3c.github.io/webrtc-pc/#dom-rtcsctptransportstate.
One test case was modified, as it didn't test the reality. The test
created a SctpTransport, registered an observer, and added the DTLS
transport, and expected to receive a "statechange" from `kNew` (which is
not a state that exists in the spec) to `kConnecting`. If the test had
tested the opposite ordering - adding the DTLS transport first, and then
adding an observer, it wouldn't have experienced this. And since in
reality (with the implementation of JsepTransport before and
after this CL), it always adds the DTLS transport before any observer is
registered. So it wouldn't ever be fired, outside of tests.
Bug: webrtc:15897
Change-Id: I6ac24e0a331b686eb400fcf388ece50f2ad46a32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345420
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41987}
This CL updates H26xPacketBuffer to store and prepend SPS and PPS for
H.264 bitstreams when IDR only keyframe is allowed.
Bug: webrtc:13485
Change-Id: Ic1edc623dff568d54d3ce29b42dd8eab3312f5cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342225
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41986}
This is a reland of commit 7ae48c452abf8694a1b0a7a9a2aef13a9d10298a with updated RtpVp9RefFinder
RtpVp9RefFinder relied on the fact that frames with (inter_pic_predicted=true && inter_layer_predicted=true) were marked as keyframes. Since this is not the case anymore, the related code paths in RtpVp9RefFinder have been deleted.
Calculation of gof_info_[] index for non-keyframes has been updated to account for that fact it is now possible to received multiple T0 frames belonging to the same temporal unit (we don't need to do "unwrapped_tl0 - 1" in this case).
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: Ic69b94989919cf6d353bceea85d0eba63bc500ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344144
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41985}
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}
