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}
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}
e.g all files in the api/test folder not including subdirectories
Bug: webrtc:42226242
Change-Id: I18d74a18f8feec41eb252faa9acfffd1d6f45ce4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359420
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Dor Hen <dorhen@meta.com>
Cr-Commit-Position: refs/heads/main@{#42773}
The new type PriorityValue is a strong 16-bit integer matching RFC 8831
requirements that can be built from a Priority enum.
The value is now propagated and used by the SCTP transport, but enabling
the feature still requires a field trial for now.
Bug: webrtc:42225365
Change-Id: I56c9f48744c70999a8c2d01415a08a0b6761df4b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357941
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42695}
This requires making CallConfig move-only so it can hold a unique_ptr to
the factory, but as discussed with Danil, that seems fine.
Bug: chromium:355610792
Change-Id: Ie52e33faaa4a2af748daeb25f5327b7a532936e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357862
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42679}
All calls in code under test were migrated to AudioEncoderFactory::Create and thus there is no longer need to propagate older function.
Bug: webrtc:343086059
Change-Id: I9e0ea4024759deb22c0d284e0e4bac7322a08f62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357181
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42638}
Some dependencies still exist but are a bit more complex to remove.
This CL removes either unused or easily replaced with ToString()
instances of ostream usage. In one case, moving the operator<<
implementation to the one test file that requires it.
Bug: webrtc:8982
Change-Id: Ia5c840b12a42893494af401317a3daf2fe50ba9b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356240
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42582}
Libvpx works without this, so the existing tests pass. However, other
encoder implementations (like rtc_video_encoder in Chrome) look at
different fields and get confused about the configuration.
Test: Integration tests with Chrome and windows hardware encoders.
Bug: webrtc:348342168
Change-Id: Id0d96cff34eb34c7e019a24255623f3aeeca5772
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355500
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42555}
Allow API users to access the NetworkControllerInterface instance that a
given PC ended up with, to allow integrators who have provided a
PeerConnectionFactoryDependencies.network_controller_factory to
associate a created instance of their custom network controller with the
PC using it.
Eg for the RTCRtpTransport Chromium implementation as in crrev.com/c/5607744.
Bug: chromium:345101934
Change-Id: Ia712ca4f45b90d5078f4e8e5977622d3e9f9aa6f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353980
Commit-Queue: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42506}
and move usages to webrtc::RefCountInterface
This CL also moves more stuff to webrtc:: and adds backwards
compatible aliases for them.
Bug: webrtc:42225969
Change-Id: Iefb8542cff793bd8aa46bef8f2f3c66a1e979d07
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353720
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42446}
since it contains helpers mostly related to cryptographically secure random numbers and strings.
BUG=webrtc:339300437
Change-Id: I10db939534b25dc792ac1600a4721d1b84521880
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/352620
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42441}
and files that broke when I fixed the first set.
Bug: webrtc:42226242
Change-Id: I321cd63537ab3002098c7bdecd889a6fc5a1eb25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353421
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42429}
which is showing up too often in
https://ci.chromium.org/ui/p/webrtc/builders/try/linux_tsan2
The actual failure seems to be around ice candidate destructors and what
makes this test special is that it accessed local_description() which is now avoided. MsidSignalingInSubsequentOfferAnswer shows a similar usage but seems much less flaky.
BUG=webrtc:340041654
Change-Id: Iba1369c62918c56b0904724f28109a7308cefee3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/351565
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42384}
since the tie breaker is owned by the allocator now.
BUG=webrtc:42224914
Change-Id: I76bd5ae714fb2a6df38e014991242f390ae87e6a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/351180
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42371}
with an intermediate step since Chromium depends on the openssl_stream_adapter.h which will move to the new target.
BUG=webrtc:339300437
Change-Id: Iea163e0a6e3923ce8a741a2e11e9a2a1e3f3e7a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350887
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42362}
reduced-size RTCP, i.e. not prefixing RTCP packets with either a sender report or receiver report has been implemented for a long time but only for video.
This CL adds it for audio as well. This reduces the size of audio NACKs (16 bytes, typically one NACK per packet) sent by not prefixing it with a receiver report (32 bytes).
Other packets are not affected as e.g. transport-cc feedback does not add a RR even though that is technically required.
The effect on NACK can be tested by running Chromium with
--disable-webrtc-encryption --force-fieldtrials=WebRTC-FakeNetworkReceiveConfig/loss_percent:5/
against this fiddle negotiating audio nack:
https://jsfiddle.net/fippo/8ubtLnfx/1/
BUG=webrtc:340041654
Change-Id: I06fb94742ff1b6f9a464c404bfc53913f23498d8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350269
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42330}
Intended use is to convert between different representations of "codec".
Bug: webrtc:42226302
Change-Id: If6d985ad17c2ff6018c77c7858e602b9eefa9297
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350562
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42319}
Replace usage of BuiltInNetworkBehaviorConfig.link_capacity_kbps in tests with DataRate link_capacity.
Bug: webrtc:14525
Change-Id: Id1c1b8d20eb2be5e9d1461704bb7c37c61c491f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350300
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42306}
This is a reland of commit 47bfe39ecfe45b2f94c616ace97949003d9e87b4
Original change's description:
> Split digest methods from ssl target into digest target
>
> in an attempt to break up the monolithic ssl target.
>
> BUG=None
>
> Change-Id: I38f5b3e2828742d5d918460db1af0a5797d6a5c2
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349764
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Philipp Hancke <phancke@meta.com>
> Cr-Commit-Position: refs/heads/main@{#42249}
Bug: webrtc:339300437
Change-Id: I31bb79bbc6cc55a2634176f95ec67de195974e1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350260
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42304}
in an attempt to break up the monolithic ssl target.
BUG=None
Change-Id: I38f5b3e2828742d5d918460db1af0a5797d6a5c2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349764
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42249}
