dcSCTP seems to be able to provoke usrsctp to send ABORT in some
situations, as described in
https://github.com/sctplab/usrsctp/issues/597. Using a packetdrill
script, it seems as a contributing factor to this behavior is when a
FORWARD-TSN chunk is bundled with a DATA chunk. This is a valid and
recommended pattern in RFC3758:
"F2) The data sender SHOULD always attempt to bundle an outgoing
FORWARD TSN with outbound DATA chunks for efficiency."
However, that seems to be a rare event in usrsctp, which generally sends
each FORWARD-TSN in a separate packet.
By doing the same, the assumption is that this scenario will generally
be avoided.
With many browsers and other clients using usrsctp, and which will not
be upgraded for a long time, there is an advantage of avoiding the issue
even if it is according to specification.
Before this change, a FORWARD-TSN was bundled with outgoing DATA and due
to this, it wasn't rate limited as the overhead was very little. With
this change, a rate limiting behavior has been added to avoid sending
too many FORWARD-TSN in small packets. It will be sent every RTT, or
200 ms, whichever is smallest. This is also described in the RFC.
Bug: webrtc:12961
Change-Id: I3d8036a34f999f405958982534bfa0e99e330da3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229101
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34801}
All decoders are supposed to be able to decode all valid bitstreams
that can be produced by an encoder. In the cases where this is not
the case, reference_scaling better captures the cause of this than
scalability_mode which was used initially.
Bug: chromium:1187565
Change-Id: I21174077badf0fb9d90b1b58f003edac5b8ee0f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229184
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34800}
This is a reland of 3097008de03b6260da5cfabb5cbac6f6a64ca810
Patchset 1 is a pure reland. Patchset 2 contains a bugfix plus a test
covering that case.
Bug: webrtc:12354, chromium:1230448
Original change's description:
> Rename vp9::FrameInfo to vp9::UncompressedHeader and add more fields.
>
> These fields will be used for bitstream validation in upcoming CLs.
> A new vp9_constants.h file is also added, containing common constants
> defined by the bitstream spec.
>
> Bug: webrtc:12354
> Change-Id: If04256d83409069c8bee43ad41aed41c3707dfd3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226060
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Philip Eliasson <philipel@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34476}
Bug: webrtc:12354
Change-Id: Ibd301eb458a6104b562cefbc0e616c39b54fb38b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229060
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34789}
Setting different number of temporal layers is supported by SimulcastEncodeAdapter and LibvpxVp8Encoder will fallback to SimulcastEncoderAdapter if InitEncode fails.
Bug: none
Change-Id: I8a09ee1e6c70a0006317957c0802d019a0d28ca2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228642
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34785}
Using usrsctp_getladdrs() would sometimes be flagged by TSAN for a lock
order inversion. It was used to retrieve the "id" of the socket on the
transport.
The "id" is instead stored in the "ulp_info" parameter, which is
passed with each callback from usrsctp.
Bug: webrtc:12823
Change-Id: Ifb3d7780273a460e677526dd3a93f9365b29300c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229000
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34784}
turning the current field trial into a killswitch.
Note that RED is not used by default since it is listed after opus in the SDP.
To enable RED for opus the setCodecPreferences can be used to change
the order of codecs.
BUG=webrtc:11640
Change-Id: I248f4340ca0a3f7c4ea6d6a41b566bc92ab6f19d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228426
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34781}
Before this CL PeerConnectionE2EQualityTestSmokeTest was actually
overwriting this field trial:
[ RUN ] PeerConnectionE2EQualityTestSmokeTest.Smoke
(field_trial.cc:140): Setting field trial string:WebRTC-UseStandardBytesStats/Enabled/
(field_trial.cc:140): Setting field trial string:
(network_emulation.cc:480): Created emulated endpoint 192.168.0.0 (); id=1
(network_emulation.cc:480): Created emulated endpoint 192.168.0.1 (); id=2
(field_trial.cc:140): Setting field trial string:WebRTC-FlexFEC-03-Advertised/Enabled/WebRTC-FlexFEC-03/Enabled/
After this CL it is instead used:
[ RUN ] PeerConnectionE2EQualityTestSmokeTest.Smoke
(network_emulation.cc:480): Created emulated endpoint 192.168.0.0 (); id=1
(network_emulation.cc:480): Created emulated endpoint 192.168.0.1 (); id=2
(field_trial.cc:140): Setting field trial string:WebRTC-UseStandardBytesStats/Enabled/WebRTC-FlexFEC-03-Advertised/Enabled/WebRTC-FlexFEC-03/Enabled/
This CL also removes the non effective field trial override in
test/pc/e2e/peer_connection_e2e_smoke_test.cc which was unset as soon
as the variable was going out of scope.
Bug: b/186198412
Change-Id: I1698407e2c490a80c1f835cd591624446cf993fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229023
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34779}
The congestion window is unlikely to be even divisible by the size
of a packet, so when the congestion window is almost full, there is
often just a few bytes remaining in it. Before this change, a small
packet was created to fill the remaining bytes in the congestion window,
to make it really full.
Small packets don't add much. The cost of sending a small packet is
often the same as sending a large one, and you usually get lower
throughput sending many small packets compared to few larger ones.'
This mode will only be enabled when the congestion window is large, so
if the congestion window is small - e.g. due to poor network conditions,
it will allow packets to become fragmented into small parts, in order to
fully utilize the congestion window.
Bug: webrtc:12943
Change-Id: I8522459174bc72df569edd57f5cc4a494a4b93a8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228526
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34778}
For symmetry, as the outstanding_bytes is increased/decreased by
the serialized chunk size (not just the payload) - which is compared
to the congestion window, the congestion window should be increased
by the serialized size of chunks acked - not just their payload.
Bug: webrtc:12943
Change-Id: I0a06033e8ca0d58433138df6442ca80494918cf2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228525
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34775}
The same code was done for both acking chunks due to moving the
cum-ack-tsn and when acking gap-ack-blocks. Unify them completely
to have a single code path.
Bug: webrtc:12943
Change-Id: I3b864e41cc2ec674460517660c23b72a70edf720
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228521
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34773}
This is mainly a refactoring commit, to break out packet sending to a
dedicated component.
Bug: webrtc:12943
Change-Id: I78f18933776518caf49737d3952bda97f19ef335
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228565
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34772}
Before this change, there was no way for a client to indicate to the
dcSCTP library if a packet that was supposed to be sent, was actually
sent. It was assumed that it always was.
To handle temporary failures better, such as retrying to send packets
that failed to be sent when the send buffer was full, this information
is propagated to the library.
Note that this change only covers the API and adaptations to clients.
The actual implementation to make use of this information is done as a
follow-up change.
Bug: webrtc:12943
Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34767}
We already default to PipeWire 0.3 and there is no reason to keep
continue supporting an old version of PipeWire which is not maintained
anymore, wont't get any update or new features. It also makes the code
easier to understand since we can remove all ifdefs we had to support
two versions simultaneously.
Bug: chromium:1146942
Change-Id: I7156e1784ebfad111485a2944199563568a75eec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227345
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34765}
Enabling bitcode doesn't seem to create a separate dSYM.
To make it work in this configuration, when creating an XCFramework,
pass dSYM only if it exists.
Bug: none
Change-Id: I6d95dc765accc10a70caeb88063d05eeea630dd1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228700
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34762}
from runtime check in proxy classes that picks decoder (VCMDecoderDataBase)
to a DCHECK in the VideoDecoder::Settings
Bug: None
Change-Id: Ic8c2e971486a3a7eb247f9d03815aba5ca5a7bad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228644
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34761}
