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}
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}
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}
Based on https://webrtc-review.googlesource.com/c/src/+/362740 we can now simplify the MergeRtpHdrExts since there is no longer need to keep track of the `regular_extensions` and `encrypted_extensions` separately.
Bug: chromium:40623740
Change-Id: Iff94931e87a7b9301ac58d4c5c2c975b9f9fe57a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363880
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#43107}
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}
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}
The code that restricts the maximum number of simulcast layers based on
resolution is a spec-compliance bug and doesn't make much sense: if the
app asks for 3 layers it should get 3 layers. Since the app knows the
size of the track, it could very easily ask for 1 layer when resolution
is small if that is the behavior it wanted. If the app doesn't ask to
disable layers, WebRTC shouldn't disable layers on its behalf.
This behavior makes even less sense with this "new" API since the app
is explicitly controlling the send resolution in absolute terms.
Removing this behavior in the general case is out of scope since it
would break backwards compatibility, but since `requested_resolution`
has not been exposed to the web yet and existing usage is small, this
is an opportunity to fix the compliance bug for this API.
This CL makes the last web platform test for "scaleResolutionDownTo"
pass.
Bug: chromium:363544347
Change-Id: Ic6fadf3cad69d3beec4ae03d3d031e8062382ad9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363100
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43061}
When a value is set in RtpEncodingParameters::codec, the corresponding
payload_type will be set in the SDP a=rid: line.
a=rtpmap:96 VP8/90000
...
a=rtpmap:97 VP9/90000
...
a=rid:r0 send pt=96
a=rid:r1 send pt=97
Bug: webrtc:362277533
Change-Id: Ia9688a5fc83c53cf46621d97e87f8dd363a4d7f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361240
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43049}
This adds payload types to the codecs at the time when offer
is being generated, if they are unassigned at that point.
Bug: webrtc:360058654
Change-Id: I231ed057ebaf7fb0fffaf6ff5d600b064ba21f5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362282
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43033}
When it waits for only one frame, the test is flaky.
When it waits for two frames, it is not.
# Relying on triviality for confidence due to purple bots atm,
# see b/367211396
NOTRY=True
NOPRESUBMIT=True
Bug: webrtc:367205682, webrtc:42220900
Change-Id: I14963b7a86961f438fd511aba8f29525e1f19750
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362583
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43025}
which may show useful debug logging.
Also document that we need to forward-declare the internal srtp_ctx_
struct instead of srtp_t.
BUG=webrtc:361372443
Change-Id: I76b1a4fb385af0fc1532f0ce6d0692b804f003dd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360182
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43022}
This API should not modify the aspect ratio of the frame, e.g. if the
frame is 1280x720 and requested_resolution is 1280x360, the result
should be 640x360, not a streched out 1280x360 frame. The spec version
of this API calls this "maxWidth" and "maxHeight" which is the right
way to think about it rather than a forced width and height.
VideoAdapter continues to be used to apply adaptation restrictions, but
we now make sure to calculate the correct frame size BEFORE applying
restrictions. Prior to this CL, the VideoAdapter was also used to apply
requested_resolution restrictions. This is actually wrong and would
cause strange scaling factors in some cases, e.g. f=1280x720 + r=720x405
would result in 640x360 instead of 720x405. Now we make f=720x405 first
and only adjust further if restrictions or alignments require us to.
Since this is a change in behavior a WebRtcVideoChannelTest is updated.
Encodings integration test is also added, both for aspect ratio (new
behavior) and orientation agnosticism (old behavior still passing).
Bug: webrtc:366067962
Change-Id: I4e8dc27da5a84d73238b8ab74ef197eb5ee8072a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362101
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43020}
This allows detecting if it has been set reliably.
0 is a valid payload type.
Bug: webrtc:360058654
Change-Id: Ic3646abe20d0247592145ad27549fa46ddb7ec90
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362261
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43016}
This CL makes `requested_resolution`, which is the C++ name for what
the spec calls scaleResolutionDownTo, align with the latest PR[1].
The PR says to ignore scaleResolutionDownBy when scaleResolutionDownTo
is specified as to be backwards compatible with scaleResolutionDownBy's
default scaling factors (e.g. 4:2:1). Ignoring is different than what
the code does today which is to throw an InvalidModificationError.
We don't want to throw or else get+setParameters() would throw by
default due to 4:2:1 defaults so the app would have to remember to
delete these attributes every time even though it never specified them
(Chrome has a bug here but fixing that would expose this problem, see
https://crbug.com/344943229).
[1] https://github.com/w3c/webrtc-extensions/pull/221
Bug: none
Change-Id: I21165c9b9f9ee7259d88b89f9ae58b862ea4521e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362260
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43002}
* IWYU export <sys/socket.h> from rtc_base/net_helpers.h.
* Add a presubmit check to ensures that <sys/socket.h> is included through net_helpers.h (expect if there is a IWYU pragma or a no-presubmit-check).
* Clean up existing includes of <sys/socket.h>
Change-Id: I4bc6cce045c046287f8f74f89edfc9321293b274
Bug: b/236227627
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362082
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#42996}
This entails passing in a PayloadTypeSuggester as a dependency. PT suggesting is still done according to the old method, but with new code.
Bug: webrtc:360058654
Change-Id: I12a7d2aa6aa482fb62ff3dfb34b9761ebb7dddef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361200
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42989}
Disable the checks ensuring we reject mixed-codec simulcast
when the field trial is enabled.
The feature is however not yet implemented.
Bug: webrtc:362277533
Change-Id: Ib1601767c951d61aaa37a3d8767d0a81444d626c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361404
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42942}
Since media/ and pc/ both have to use this, and both
depend on call/, this seems to be the right place to put it.
Also factor out the interface that media will use in a separate
interface class.
Bug: webrtc:360058654
Change-Id: I34acbecc618f23e19542ce4b0110d0e8ed9e55ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361281
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Auto-Submit: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42933}
Will be later used to conditionally enable mixed codec simulcast
with a field trial.
Bug: webrtc:42220378
Change-Id: I527a488c04cd2b5a9f4ec703504b67943e966ab0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361403
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42929}
which broke since libsrtp included openssl/srtp.h instead of
its own srtp.h due to the order of include directories
BUG=webrtc:42234521
Change-Id: Idc5cba2114febd1e0835d201b6c23424a88e62d1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360705
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42913}
- Modify munger to take (mutable)
std::unique_ptr<SessionDescriptionInterface> rather than
cricket::SessionDescription (that latter is embedded in the former)
- For all pranswer test cases, do a final SetRemoteDescription(kAnswer) and
check that signaling_state == stable
Add new test cases:
1) A test case that only applies it as prAnswer on caller (callee is stable)
2) A test case that "scramble" sdb between prAnswer and Anser.
Bug: None
Change-Id: Ifedd92ade01ae781a2e59d0569133c486c7093fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360781
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42891}
When declaring a lambda with a value-capture default `[=, ...]`, the
this pointer is implicitly captured by value as well. This results
in potentially-unintuitive behavior and has been deprecated in C++20.
It produces a warning in newer versions of clang
(https://reviews.llvm.org/D142639).
Unfortunately, the preferred C++20 pattern `[=, this, ...]` is not compatible with previous C++ versions. To maintain compatibility with C++14, 17, and 20, this CL modifies all lambdas which capture `this` to explicitly capture all the necessary variables, with no capture-default.
Bug: chromium:351004963
Change-Id: I10c4a9669f340efba75a3e4016f0988a2d606d1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357322
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Devon Loehr <dloehr@google.com>
Cr-Commit-Position: refs/heads/main@{#42886}
Normally (scaleResolutionDownBy) restrictions are applied at the source
which changes the input frame size which triggers reconfiguration with
appropriate scaling factors.
But when requested_resolution is used, encoder settings are by
definition not relative to the input frame size. In order for
restrictions to have an effect, they are applied inside
ReconfigureEncoder(): you get the minimum between the requested
resolution and the restricted resolution.
ReconfigureEncoder() happens when you SetParameters(), but the bug
here is that we don't do it again once the restrictions are updated.
So if restrictions are 540p when you ask for 720p, you get 540p and
after restrictions change to unlimited you're still stuck in 540p.
The fix is to also trigger ReconfigureEncoder() inside
OnVideoSourceRestrictionsUpdated() when the restricted resolution is
changing and a requested_resolution is configured.
To ensure reconfiguring the encoder "on the fly" like this does not
reset initial frame dropping logic, InitialFrameDropper caring about
input frame size changing is made conditional on not using
requested_resolution.
# Slow purple bots failing but they are not affected by this change.
NOTRY=True
Bug: webrtc:361477261
Change-Id: I1389aa16cf408b0d14e0b5b6f68c2442db955be9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360200
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42882}
Before this cl, ReadyToSend signaled false if sending a packet failed and transport->GetError() returns ECONN.
ECONN may be reported by the TCP connection (TcpConnection) if the remote closed the connection. TcpConnection will attempt to reconnect and should change the writable state if it fail.
Changing the state in the context of sending packets may cause recursive
calls and seems to cause problems with incorrect states.
It is simpler if RtpTransport::SendPacket ignore these failures and
upper layers treat these lost packets similar to if the packets had been
lost via UDP.
For safety, this change can be reverted by field trial WebRTC-SetReadyToSendFalseIfSendFail/Enabled/.
Bug: webrtc:361124449 b/359989715
Change-Id: I8e7016dfb4301862286215c4512aa8ac03a16685
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360120
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42868}
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}
