as preparation for H265 work.
BUG=webrtc:15703
Change-Id: Ib6e0afa5ccbb8172a70d4e4eb876639559070fd6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329981
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41350}
This is temporary and should be re-enabled as soon as the test is
fixed.
Bug: webrtc:15722
Change-Id: I9d262c9931a19bc9c33f7f93e9e275d39fab403c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330561
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41348}
This allow exernal applications to control how many packets can be sent relative current BWE.
This is a partial revert of https://webrtc-review.googlesource.com/c/src/+/311102
Bug: chromium:1354491
Change-Id: Ia236aaacc468ddac12341efa555041bb2dfdde62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330580
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41343}
This reverts commit 33c7edd58ad0edc71939b9372fff3ab563c1f4a7.
Reason for revert: Breaks downstream project
Original change's description:
> Enable DD and VLA header extensions by default for Simulcast/SVC
>
> When Simulcast (more than one encoding) or SVC (a scalability mode
> other than the default L1T1) is used, enable the AV1 Dependency
> Descriptor and the video-layer-allocations RTP header extensions by
> default.
>
> The RTP header extensions API can be used to disable them if needed.
>
> BUG=webrtc:15378
>
> Change-Id: I587ac32c9d681461496a136f6950b007e72da86d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326100
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#41332}
Bug: webrtc:15378
Change-Id: I6b5f71f321d30a510db3bd180deaa57732f9349b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330540
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41341}
In the example below, the association is being established between peer
A and Z, and A is the initiating party.
Before this CL, when an association was about to be established, Z would
after having received the INIT chunk, persist state in the socket about
which verification tag and initial TSN that was picked. These would be
re-generated on every incoming INIT (that's fine), but when A had
extracted the cookie from INIT_ACK and sent a reply (COOKIE_ECHO) with
the state cookie, that could fail validation when it's received by Z, if
the sent cookie was not the most recent one or if the COOKIE_ECHO had a
verification tag coming not from the most recent INIT_ACK, because Z had
replaced the state in the socket with the one generated when the second
INIT_ACK chunk was generated - state it used for validation of future
received data.
In other words:
A -> INIT 1
<timeout>
A -> INIT 2 (retransmission of INIT 1)
INIT 1 -> Z - sends INIT_ACK 1 with verification_tag=1, initial_tsn=1,
cookie 1 (and records these to socket state)
INIT 2 -> Z - sends INIT_ACK 2 with verification_tag=2, initial_tsn=2,
cookie 2 (replaces socket state with the new data)
INIT_ACK 1 -> A -> sends COOKIE_ECHO with verification_tag=1, cookie 1
COOKIE_ECHO (cookie 1) -> Z <FAILS, as the state isn't as expected>.
The solution is really to do what RFC4960 says, to not maintain any
state as the receiving peer until COOKIE_ECHO has been received. This
was initially not done because the underlying reason why this is
important in SCTP is to avoid denial of service, and this is why SCTP
has the four-way handshake. But for Data Channels - SCTP over DTLS -
this attack vector isn't available. So the implementation was
"simplified" by keeping socket state instead of encoding it in the
state cookie, but that obviously had downsides.
So with this CL, the non-initiating peer in connection establishment
doesn't keep any socket state, and puts all that state in the state
cookie instead. This allows any COOKIE_ECHO to be received by Z.
Bug: webrtc:15712
Change-Id: I596c7330ce27292612d3c9f86b21c712f6f4e408
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330440
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41340}
These functions had dummy implementations, but were not virtual.
The need for those functions seems to be lost in time.
Bug: None
Change-Id: I66dcac4a92f9993d82031f943f2f9ae767156b8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330422
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41336}
as a step to propagate Environment and thus field trials into Decoders
Bug: webrtc:10335
Change-Id: Ib396421f0fbf34f2c2f90aa4a1b41b461e42253c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330421
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41335}
When Simulcast (more than one encoding) or SVC (a scalability mode
other than the default L1T1) is used, enable the AV1 Dependency
Descriptor and the video-layer-allocations RTP header extensions by
default.
The RTP header extensions API can be used to disable them if needed.
BUG=webrtc:15378
Change-Id: I587ac32c9d681461496a136f6950b007e72da86d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326100
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#41332}
Now that Chromium has migrated to the new name[1], "decode_metronome",
we can delete the variable with the old name, "metronome".
[1] https://chromium-review.googlesource.com/c/chromium/src/+/5093942
Bug: webrtc:15704
Change-Id: I50fef88a692d83e37af10956b2e12389fa601662
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330300
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41331}
while cleaning up Call factory function,
- pick rtp_transport_controller_send_factory based on presence in the config instead of based on the call site thus removing one extra factory function.
- when Call is created through test helper TimeControllerBasedFactory use original media factory instead of direct factory, thus allow to configure degraded call through field trials in tests, and ensure difference with production code path stay minimal in the future.
Bug: webrtc:15656
Change-Id: If9c2a9fc871e139502db2bec0a241d8d64c53720
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330061
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41329}
ConntectionContext now keeps and expose field trials as part of the
Environment, and do not need to be aware about field trials specifically
Bug: webrtc:15656
Change-Id: Ib78694a65a9ca7c8bf273eeaf9334323ddb841c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329420
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41328}
This function isn't used anymore.
Bug: webrtc:9987
Change-Id: I37f1c86cc4802950347db302e8a9207b9dd370bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330261
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41327}
Replace CallFactory class with a factory function
Bug: webrtc:15574
Change-Id: Ib1d8cff8d7550da3af01693a7bc117a7bd342258
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330000
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41321}
In preparation for experimentally supporting different types of
metronomes and metronome use cases we'd like to rename for clarity.
This is the first step, which introduces the new name and prefers it if
it is set, but keeps the old name for backwards compat reasons.
Once Chromium has migrated to the new name, we can delete the old name.
Bug: webrtc:15704
Change-Id: I23077bf2415ebb2b2338320c9a14e3bd17d3abb6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330020
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41319}
This is a replacement for `connections()`, which is const-qualified but
returns a `rtc::ArrayView<const cricket::Connection*>`. Unfortunately,
this is a view of mutable pointers to `const cricket::Connection`
objects: this means that the pointers in `IceControllerInterface`'s
backing store can be reassigned.
Returning `rtc::ArrayView<const cricket::Connection* const>` is more
consistent with how a view returned from a const-qualified method should
behave. Unfortunately, there are downstream overrides of this method, so
instead of just fixing this outright, add a new method with the correct
return type. Once downstream is updated, the old method can then be
removed.
Bug: chromium:1409870, webrtc:15702
Change-Id: I3d8f0c2f0bcf4c393ee63959cb61761ac00a28ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329962
Reviewed-by: Jonas Oreland <jonaso@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41318}
These are added to ease the transition to uint8_t for downstream code.
Bug: webrtc:15665
Change-Id: I571805b93ddd19be6f6990ce34f5c248a57f36b3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329763
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41315}
And the same for outstanding items, which become unacked items. The old
names were unfortunate - especially since they were managed by a class
called OutstandingData.
To make this less complicated, these variables have been renamed to
something that is easier to understand; "Unacked bytes/items". Simply
what has been sent but hasn't been acked or nacked yet. So likely what's
in-flight, but could possibly be lost and not found to be lost yet.
Bug: None
Change-Id: I877d7f2cac5d164bf2f9f66cb32ae1f6d850ad2c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329761
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41313}
A std::map is a fairly inefficient data structure. Accessing an item
is O(log(N)), but as every item is a separate allocation, iterating it
and searching for items is not very kind to the data caches.
As the outstanding data is a contiguous list (no gaps) where you only
append to the end and remove from the front, use a std::deque instead.
Bug: webrtc:15699
Co-authored-by: Daniel Collins <dpcollins@google.com>
Change-Id: I1f5fe97d06204c75b2b9553856af24e50f2ce715
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329422
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41310}
This change ensures that the FCA now is informed about a new max fps
when VideoStreamEncoder::OnVideoSourceRestrictionsUpdated is called.
The latest restricted frame rate which is provided to the FCA will
only affect the cadence of repeated non-idle (quality has not
converged) frames and the main goal is to ensure that the FCA reduces
its repeat rate in situations where the video source is constrained.
UpdateVideoSourceRestrictions is added to the FrameCadenceAdapter API
and it is called from the VideoStreamEncoder when its source
parameters (resolution and/or frame rate) are restricted.
This modification has no effect on the flow driven by
ProcessOnDelayedCadence (non repeated frames).
Bug: webrtc:15539
Change-Id: I26dee6480e5137f82c5ccf57091b737cad82dbf6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/328300
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41308}
This reverts commit ad631f0d353011b8d4282577310abb48bf60ff67.
Reason for revert: error: virtual function 'connections' has a different return type ('ArrayView<const cricket::Connection *>') than the function it overrides (which has return type 'ArrayView<const Connection *const>')
Original change's description:
> Correctly const-qualify return value of IceControllerInterface::connections().
>
> This is intended to be a read-only view across a container of const
> Connection*, but due to the missing const, elements of the container
> could actually be re-assigned through the ArrayView.
>
> This was discovered when trying to roll Googletest, since Googletest was
> fixed to const-qualify converting actions:
> cbca6bc395
>
> Bug: chromium:1409870
> Change-Id: Iadd3abe6807111987e422b8510a23f2a4f7026ed
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329481
> Auto-Submit: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Daniel Cheng <dcheng@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#41300}
Bug: chromium:1409870
Change-Id: Id0026eb7727a3d1408045d0040b3b080cca07832
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329762
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Manashi Sarkar <manashi@google.com>
Cr-Commit-Position: refs/heads/main@{#41307}
Previously, ByteBufferWriterT could only be instantiated for "char",
due to using "char" internally. The rewrite extracts the inner type
from the BufferT parameter and uses that.
This is preparatory to changing its type to "uint8_t".
Bug: webrtc:15665
Change-Id: Ib771d37e3abb8261049c16122c6b43dcb561e9a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329680
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41306}
