This change makes AudioCodingModule a pure sender and AcmReceiver a pure
receiver.
The Config struct is in practice no longer used by AudioCodingModule,
so a new definition is included in AcmReceiver. The old definition
remains in AudioCodingModule while downstream clients are being
updated.
Bug: webrtc:14867
Change-Id: If0d0b4214c5aa278cf6c85c5b62c6da644de20e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291533
Reviewed-by: Tomas Lundqvist <tomasl@google.com>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39244}
This is used when an unsignaled stream with a known payload type is received and later a RTX packet is received.
Bug: webrtc:14817
Change-Id: I29f43281cec17553e1ec2483e21b8847714d2931
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291328
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39243}
as described in https://w3c.github.io/webrtc-extensions/#modifications-to-existing-procedures-0
"For each RTP header extension "e" listed in
[[HeaderExtensionsToOffer]] where direction is not "stopped", an
"a=extmap" line, as specified in [RFC5285], section 5
This avoids including them in case they are stopped on one
transceiver but not the other. Also, this allows extensions to
be removed from a subsequent offer.
See also
https://github.com/w3c/webrtc-extensions/issues/140
BUG=chromium:1051821
Change-Id: I4d7462f939ce4cd5d8c2331bc038200fe18f70e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291703
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39242}
The lowest level and some of the highest levels of this function are
already using ArrayView. Make this consistent throughout.
Use deprecation for the old API rather than deleting it, since upstream
may be using it.
Bug: webrtc:14870
Change-Id: If5e1a6e9802ecf7e8e3ec27befb5167ca9985517
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291706
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39241}
Before this, an empty list of CSRCs was always provided up to encoded
insertable streams transforms for remote video tracks, regardless of
the actual CSRCs on received frames. Audio already works correctly.
Bug: chromium:1411614
Change-Id: I51ab4dc5e67a1a35893fefff16c1f057e9047e6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291539
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#39240}
The mouse_cursor_monitor_unittest.cc was disabled on all platforms, so
it can be deleted.
Bug: webrtc:3408
Change-Id: I294bc502993a5b0a369a60a751c72f72ec909dfc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291724
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39239}
This is a port of crrev.com/c/2936677.
Previously we only checked avx2 support and then use avx2/fma
intrinsics in SincResampler(crrev.com/c/2654647),this CL also
checks the fma support and avoids using avx2 code if fma is not
supported.
Bug: chromium:1410691
Change-Id: Ibf7c0a1bead87ebe5d3978cfd20cc23525169f40
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291702
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39238}
These configurations are no longer used by call. Header extensions are identified once when demuxing packets in WebrtcVideoEngine::OnPacketReceived and WebrtcVoiceEngine::OnPacketReceived.
Change-Id: I49de9005f0aa9ab32f2c5d3abcdd8bd12343022d
Bug: webrtc:7135
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291480
Owners-Override: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39236}
This is a prerequisite step to break apart AudioCodingModule and AcmReceiver.
Bug: webrtc:14867
Change-Id: Iba589c7a31b6346ff4acb727793d84077162c8c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291534
Auto-Submit: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Tomas Lundqvist <tomasl@google.com>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39235}
This ensures that adding features by SDP munging gets a review
by people who understand how this works in the community.
Bug: none
Change-Id: I36feb0e3c7896d4f7bec81078109d7914c349a0d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291339
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39229}
For frames captured and sent to the callback immediately, we
are not sending the capturer ID as we used to do in base capturer
pipewire. Adding the capturer id as well as the frame capture time
so as to keep the sent frame to be in sync with the
non-immediate-frame-send implementation.
Bug: chromium:1291247
Change-Id: I02693907928b9e770ea56f89b46c37f17f4bc4a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291680
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39228}
Today, behaviour is decided based on if transport sequence number v2 is
in the SDP answer. But it might be better to decide based on received
packets since it is valid to negotiate both extensions.
Another bonus With this solution is that Call does not need to know
about receive header exensions.
This is an alternative to https://webrtc-review.googlesource.com/c/src/+/291337
Bug: webrtc:7135
Change-Id: Ib75474127d6e2e2029557b8bb2528eaac66979f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291525
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39226}
Remove integration with socket server of the current thread
Network thread that uses PhysicalSocketServer shouldn't be allowed to do blocking calls
Other threads that use NullSocketServer do not need to process any messages while blocking
Bug: webrtc:14856
Change-Id: I56865b86e0992e60376ecefe163ff6b23911edca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291527
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39225}
which potentially allows switching to that pattern in the future.
Video FEC mechanisms (ulpfec, flexfec-03, RED) that currently
do not have any feedback parameters but will still be considered "common" and feedback may be sent for them.
For audio this causes rtcp-feedback to be sent for G711 and G722 if negotiated.
BUG=webrtc:14802
Change-Id: I54852d39e176f918d4b36462526ceb40617b8fbe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290702
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39224}
Earlier, we were relying on CRD to periodically do frame captures.
This is however not needed since Wayland captures are event based
and once the compositor has send the event/frame to us, we can just
handover the frame to a registered callback. This ensures that we
have a single frame clock that (i.e. one present in the compositor).
Without this change, there is a chance that CRD capture clock is run
out of sync with the compositor's clock and cause unnecessary frame
delays.
See the following ideal scenario, for example, where '+' indicates
when a frame is sent by the compositor and when CRD tries to capture
it. This assumes that the same clock cycle for both CRD and the
compositor, each cycle length is enclosed within | .... |).
Compositor Frame Ready | +... | | +... |
CRD Frame Capture | .+.. | | .+.. |
In this case, when both the clocks are in sync, CRD is able to
capture frame right after it is generated by the compositor. But if
they are completely out of sync, then CRD can always see a stale
frame (delayed by one cycle and it can cause users to feel stutter).
Compositor Frame Ready | .+.. | | .+.. |
CRD Frame Capture | +... | | +... |
This stutter can become worse if the compositor is delayed in
generating the frames for some reason (e.g. load on the system).
Bug: chromium:1291247
Change-Id: I7c10c724fbbd87dc523d474e7ece8e8aa146fd7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291080
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39218}
This change adds support for renegotiating the frame rate
via pipewire.
Bug: chromium:1291247
Change-Id: Iacd4a3c924900839a8db75a50b448df6c48c83ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291460
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39216}
Allow CSRCs to be modified per-frame in an Encoded Insertable Streams
transform, to support a web API which allows per-frame CSRC
modifications to signal when a JS application has changed the source
of the video which is written into an encoded frame.
Initially only for Video, with Audio support likely to follow later.
Bug: webrtc:14709
Change-Id: Ib34f35faa9cee56216b30eaae42d7e65c78bb9f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291324
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tove Petersson <tovep@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#39214}
This removes the previous approach where we continued to update the timestamp when the capturer is running but the send stream is stopped in favor of a more general approach that also works when the capturer is paused.
Some assumptions for this change to be correct: input sample rate and frame size will be the same before/after the stream is paused.
Bug: webrtc:12397
Change-Id: I3b03741cd6d3285cbc9aee3893800729852e6cfa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291526
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39213}
This ensure BWE works as intended with transport sequence numbers on
audio.
Tested with webrtc_perf_tests --gtest_filter=CallPerfTest.Min_Bitrate_VideoAndAudio
and --gtest_filter=Rampup*
Bug: webrtc:14854, webrtc:7135, b/266786240
Change-Id: I3b7a743149c22035e582a2157b5f0a93747857cf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291523
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39208}
This is to clear any remaining buffers and other state such as the next packet timestamp.
Bug: webrtc:12397
Change-Id: I2ef9a6f7254d82a69a2896ec8aa619ced2694fb8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291327
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39206}
This CL adds an unittest that a ChannelReceive can be constructed
and destroyed without crashing. It is a basis for further testing.
Lack of unit test was discovered while pursuing bug mentioned below.
Bug: webrtc:13931
Change-Id: Iddb110f2df25e3806c74a5d00bbfab6d6d8e267f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291338
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39200}
