The current solution does not work for GFD since GFD is only parsed from the first packet of the frame. As a result, to access the generic information, we have to check every packet when traversing the packet buffer to find the first packet of frame. This fix is necessary to ensure temporal scaling works correctly with GFD.
Bug: webrtc:42225186
Change-Id: Iadda4ec690deab62c32eb6101583e6a6d75cfeaf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344840
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42836}
Controlled via added field trial WebRTC-ElasticBitrateAllocation.
Bug: webrtc:350555527
Change-Id: If57552144bd4a50421d618fd8bdab31d7c4afc35
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359506
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Dan Tan <dwtan@google.com>
Cr-Commit-Position: refs/heads/main@{#42834}
According to spec, if you ask for three encodings you get three
encodings (duh). But according to legacy code, if you ask for three
encodings AND codec is VP9, then surely you meant a single encoding that
is kSVC where the other encodings influence the scalability mode of the
first encoding.
Standard simulcast support in VP9 was shipped as an opt-in feature where
you have to specify `scalability_mode` and `scale_resolution_down_by` in
order to let WebRTC know that you want to disable the legacy path.
But `scale_resolution_down_by` is not the only way to configure
resolution, there is also the `requested_resolution` code path. This CL
adds standard simulcast support for this code path as well.
Prior to this change, our parameterized test would have passed in VP8
but failed in VP9. With this change the test passes for all codecs.
Bug: webrtc:361124448
Change-Id: Ic5a7136de8abf430813fd01342862775fca145fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360100
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42822}
Fixed issue with network interfaces due to a missing return value in the
"nw_path_enumerate_interfaces(...)" block. Exposed in iOS 18,
RTCNetworkMonitor::initWithObserver will only enumerate the first
interface, instead of all device interfaces
Bug: webrtc:359245764
Change-Id: Ifb9f28c33306c0096476a4afb0cdb4d734e87b2c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359541
Auto-Submit: Corby <corby.hoback@gmail.com>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42818}
When Reconfiguring there's a call to ResetSenderCongestionControlObjects followed by a later call to
RegisterSenderCongestionControlObjects which happen on the worker thread, while enqueuing packets is
happening on a different thread.
If packets are enqueued in between these calls we get a null dereference of the `rtp_packet_pacer_`
This change fixes it by pausing processing of incoming audio in the interim state
Bug: webrtc:358290775
Change-Id: I77cebfb131545ce2a6fdb26105dd999da3f7c443
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359080
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42815}
and update some usage to use the "correct" stun attribute names
BUG=webrtc:42229250
Change-Id: If0c34d1d9b399766d7073661ea2a5515100256a5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359440
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@{#42810}
the SDP parser is restricting this to 16 bytes already
BUG=webrtc:42222663
Change-Id: I26f8f15a3f15cb5a5c8eab64f9dc3e26c0ea1bbb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359780
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42809}
Needed to get rid of a form of CreateSessionDescription that is due
for deprecation.
Bug: None
Change-Id: I9717b7ded1e28cf803de4bebc852c2f255851918
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359941
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42808}
by encryption a packet with sequence number 65535 followed
by a packet with sequence number 1. The second packet is encrypted
with a SRTP ROC of 1 as described in
https://datatracker.ietf.org/doc/html/rfc3711#section-3.3.1
The packets are (received and) decrypted in a different order,
the packet with sequence number 1 (and ROC=1) is decrypted first.
Since the ROC is maintained locally the decrypting session assumes
it to be 0.
Why is that a problem? The RFC recommends estimating the ROC with +-1 which, as demonstrated by the test, libSRTP does not.
But this is a rare problem that requires a random in a high range combined with packet loss/reordering which turns into no-a-problem if you choose carefully as done by packet_sequencer.cc which restricts the initial sequence number in the range 0..32767 which means you do not run into this issue in production.
See also Q6 in libsrtp's historical documentation at
https://srtp.sourceforge.net/historical/faq.html
BUG=webrtc:353565743
Change-Id: I9bd72b198c946937aeb25c229005a0c682447f53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358360
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42798}
There was a feature in the retransmission queue to avoid fragmenting
large messages when the congestion window was large. This was a feature
that intended to improve data channel performance under Chrome, where
communication with the network process (over MOJO) was lossy and losing
messages with small fragments could result in unnecessary
retransmissions. But back then, the implementation for fast retransmit
wasn't implemented correctly, so the benchmarking result don't
reproduce any longer.
So just improve the algorithm by removing this code. This aligns it with
the RFC and makes it easier to implement pluggable congestion control
algorithms (that wouldn't want this feature).
Bug: webrtc:42223116
Change-Id: Ifaaa82dac4b8fe2f55418158ae8b3da97199212f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359681
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42797}
Compilation errors in fuzzers are often overlooked when building locally
adding fuzzers (when configured) to build automatically helps to detect errors earlier.
list of all fuzzers was generated with a command
gn ls out/Default "//test/fuzzers:*" | grep "fuzzer$" | sed 's/\/\/test\/fuzzers\(.*\)/"\1",/'
Bug: webrtc:42223576
Change-Id: I6988e96f521a198657833e666428377d0851e1d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359762
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42794}
Mark old overload deprecated.
This allows to migrate both calls through AudioDecoderFactory and direct calls to AudioDecpderOpus trait.
Bug: webrtc:356878416
Change-Id: I1502aee5b18aac43a8258e77b770c8e73a056f92
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359741
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42793}
Current version of the dav1d decoder does not propagate any QP value to the Decoded callback. This CL updates this such that the base QP gets propagated from the frame header.
Bug: None
Change-Id: Ib7624b7e27d2c973f1821df5688cbb444e4847a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359740
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#42790}
Web Spec and C++ version of setCodecPreferences are failable, as they return
an RTCError (in C++) or throw an InvalidModificationError (in Web Spec).
However, current Objective-C version of setCodecPreferences is not failable,
so callers cannot know if the operation succeeded or not.
Also, the current Objective-C version does not accept nil, which is not
spec-compliant. (Web Spec says if codecs is an empty list, set
transceiver.PreferredCodecs to codecs and abort these steps.)
Bug: webrtc:42226103, webrtc:42226230
Change-Id: Ib90f3e5b45fc959eeb92f623cf50efcb458a7478
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/352400
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42789}
The original CL overlooked the possibility that the encoder may be
reconfigured in the middle of a stream.
Restructure the code so that all calls to QP convergence controller
happen on the encoder queue.
A side effect of this CL is that `EncodedImage::SetAtTargetQuality()`
is never called. The information is supplied to the frame cadence
adapter directly without this intermediate step.
`EncodedImage::SetAtTargetQuality()` and
`EncodedImage::IsAtTargetQuality()` are being marked as deprecated
in https://webrtc-review.googlesource.com/c/src/+/359660.
Bug: chromium:359410061
Change-Id: I941b5f60b1a9fd7694dbedf2f3e4ff5253ccf357
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359640
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42788}
