CongestrionControllerGenerator tracks received packets per SSRC.
Lost packets are included in rtcp:CongestionControlFeedback::Packets()
This is done in order to be able to track lost packets between
feedback packets.
Bug: webrtc:42225697
Change-Id: Ib47d9b55c3d150cb98a44a4f3997cfcfe6c5fbb5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366002
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43274}
This would simplify migrating from PeerConnectionFactoryDependencies::audio_processing
for users who use own implementation of the AudioProcessing
Bug: webrtc:369904700
Change-Id: Id05f7280fd01a3e8fd4953f1b24b2467335ab065
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366120
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43273}
This is similar to MatchesRtpCodec but not an exact match of parameters, unspecified parameters are treated as default. Use IsSameRtpCodec for comparison when codec is configured via encodings.
Bug: b:299588022
Change-Id: I0ea800e50af6f5666e3e867a928e15b0aa044635
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365142
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43272}
In the `MaybeProcess` method, a new variable `time_until_cc_rep` is introduced
to track the time until congestion control feedback generation is processed.
The minimum of this value and the times until RBE and transport sequence number
feedback processing are calculated.
Co-authored-by: Shridhar Majali <smajali@nvidia.com>
Bug: webrtc:42225697
Change-Id: I44173062d8f8f84bf7e7791e05578c0ffc4fd017
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365273
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43271}
Directly use RtpPacketToSend instead of RtpPacketSendInfo
For RFC8888 we will need to match SSRC and RTP sequence number with the transport sequence number that only exist on the sending side.
For retransmitted packets, RTX, RtpPacketSendInfo contain original SSRC and original sequence number.
Bug: webrtc:42225697
Change-Id: Iafa5d851ca5c51c85e4607ed4c1919d96da6084a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366000
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43264}
and use uint8_t instead of unsigned char. Follow-up from
https://webrtc-review.googlesource.com/c/src/+/365274
BUG=webrtc:357776213
Change-Id: Ibc97e5cc85316ba69b4133b7f3c42e3afbdd7abd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365540
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43263}
Indirect input deps for imported proto is now handled by deps in
proto_library template, so we don't need to use proto_data_sources
anymore after https://crrev.com/c/5919027.
To remove proto_data_sources from proto_library template, let me clean
up proto_data_sources usages from this repository.
Bug: chromium:366137880
Change-Id: I288a30004f7d622be502477a0567b00d19432e89
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366060
Auto-Submit: Takuto Ikuta <tikuta@google.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43261}
with the exception of the legacy stats collector unittest
BUG=None
Change-Id: I1ef28ab2052b1194ec788fa69606418d42d5a433
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366020
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@{#43258}
is provided by the encoder.
Note that the number of temporal streams is hardcoded to kMaxTemporalStreams (4).
Bug: b/369617423
Change-Id: I05204bc1aebc9f344d59add7b097f3e653950444
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365741
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Brennan Waters <brennanw@google.com>
Cr-Commit-Position: refs/heads/main@{#43257}
This would allow users of the voip engine to migrate away from the AudioProcessingBuilder
Bug: webrtc:369904700
Change-Id: Ie4f6f4579e185ff6366333a3f37e6aaa23b892b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365920
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43255}
This adds a Call-based test, that sets up video-pipeline with a VP8
encoder and the corruption detection header extension configured.
It then verifies that the corruption likelihood metrics are populated
in the receive stream stats.
Bug: webrtc:358039777
Change-Id: Ide005459a801778de4238e786f13efc8c3245f3f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365860
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43254}
It would allow to use EncodedImageBufferInterface with gtest container matchers.
Bug: None
Change-Id: Iae37d1a019e044a4ec583c32e8141fe0758e60ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365501
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43253}
This allows this type to meet the requirements of e.g.
std::ranges::range, which is necessary for it to work with the std::span
range constructor, or the "non-legacy" constructor for Chromium's
base::span.
Bug: chromium:364987728
Change-Id: I6cb2b9c6d849c97e304719140dcb967a9e2c254c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365780
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43251}
Compiling webrtc with `-Werror=unused-parameters` is failling duo to
those parameters.
Also, it shouldn't harm us to put those in comment for code readability as
well.
NOTE: This time I made sure to iterate over the C files in the
audio_processing folder and compile them using gcc.
On the original CL that was reverted - that failed with the same error
Danil mentioned. This time it seems fine.
I'll make sure to run the same script on the rest of my CLs for sanity
Bug: webrtc:370878648
Change-Id: I83cea3a08777e21d26a95bcad503a2d1b74566eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364537
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
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@{#43249}
We should use the Timestamp type, rather then int64, to store timestamps. In https://webrtc-review.googlesource.com/c/src/+/365001/ an additional int64 timestamp was added (last_sender_report_timestamp_ms).
This CL fixes the new timestamp, as well as other similar timestamps in MediaReceiverInfo (last_sender_report_utc_timestamp_ms and last_sender_report_remote_utc_timestamp_ms).
Bug: webrtc:372393493
Change-Id: I0e473730e85a69ec595b421e2c3db920364008eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365641
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43248}
Its implementation is a copy of the AudioProcessingBuilder with intention to replace all usage of AudioProcessingBuilder with the BuiltingAudioProcessingFactory and thus get Environment with propagated field trials available for AudioProcessingImpl at construction.
Bug: webrtc:369904700
Change-Id: Iee0eb112dd579402fcd5be56bf1054946179d1fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365582
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43242}
Instead of using AudioProcessing API directly
With AudioProcessing constructing move into the PeerConnectionFactory it is possible TestPeer doesn't have direct access to audio_processing, yet it is not null.
Bug: webrtc:369904700
Change-Id: I5a4a9453ea3a0c735da8953c9ae5d9046d4e3916
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365585
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43240}
If RTCP compound message is received with both these messages,
NetworkStateEstimator should be invoked before NetworkLinkRtcpObserver
since remote network state estimate may set limits on the BWE
calculated from the transport feedback.
Bug: webrtc:42220808
Change-Id: Ieac9c1d7d9c28e690351bcf1d8125c9e0099f962
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365583
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43239}
The `FrameToRender` function is considered a part of WebRTC's API so it cannot just be removed all at once. Since it is a pure virtual function it needs some preparation for the deprecation. This CL implements a default implementation. It will now be possible to not implement the function, but it will kill the process in that case.
Bug: webrtc:358039777
Change-Id: Ia83c63ab035abda76beb30ba98b23f9cc835a6a1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365500
Commit-Queue: Erik Språng <sprang@webrtc.org>
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43235}
This interface allows to delegate construction of AudioProcessing to
the PeerConnectionFactory where it can provide propagated field trials
Bug: webrtc:369904700
Change-Id: Ie05cd771e4a869fa5f43173e127256800ae0727f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365320
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43233}
which shows that a DtlsSrtpTransport can send and receive
from the SrtpTransport which extracts the key from its DTLS transport.
The SrtpTransport takes its keys from the DtlsSrtpTransport which
(by the way of encryption and decryption) ensures both sides agree
on the keys to use
BUG=webrtc:357776213
Change-Id: I605c6ae660eab5a53bef69bcf84d7e70a34d7be1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365274
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43231}
The split shows that some places don't need it at all. Most other
places will depend on both send and receive stream targets.
Bug: webrtc:373151158
Change-Id: I788136a2ee84180c16345a7929b7f7bf3f97507b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365460
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43230}
