This change adds below test cases:
1. Keep most recent config events on start.
2. Rewrite all previous config events on restart.
3. Do not drop events when far more events than max event history logged
on logging start.
Bug: chromium:1288710
Change-Id: Ifc227e8be788d33dc2ed65f49281b3d0809231c6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291739
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39253}
In current state, the SDP parser in webrtc is not backward compatible with clients that might still be using RTP data channels.
Obviously, this isn't there is no such usecase in webrtc since the code is deleted, but in Meta we still use it and would like
to be able to negotiate between clients that offer RTP data channels.
Instead of erroring the parsing procedure, we can parse it as unsupported media in the client that no longer supports RTP data channels.
Replaced the existing test that expects parsing failures with a test that validates that the content was parsed as unsupported media.
Bug: webrtc:14872
Change-Id: I4c105cf55e33b8c19b2849e16148b8175053c40c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291190
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39252}
This makes it possible to access cameras through xdg-desktop-portal and
pipewire.
For pipewire, a shared state is needed between the enumeration and the
creation of camera object. So a new API is needed with a shared options
object that holds the state and can be used to choose which backend to try.
Bug: webrtc:13177
Change-Id: Iaad2333b41e4e6fb112f4558ea4b623e59afcbd1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261620
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39251}
The method and config are no longer used. This concludes the work to
break apart AcmReceiver and AudioCodingModule.
Bug: webrtc:14867
Change-Id: I87219749a1ea72a01b95e960d1f32292f7352c9b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291801
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Tomas Lundqvist <tomasl@google.com>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39250}
This CL introduces VideoCodecStats and VideoCodecStatsImpl which provide baseline functionalities for storing, slicing and aggregation of encoded and/or decoded video frame statistics. To facilitate metrics logging (not implemented yet), SamplesStatsCounter is used for stream parameters.
VideoCodecStats/VideoCodecStatsImpl will replace existing VideoCodecTestStats/VideoCodecTestStatsImpl.
Bug: b/261160916, webrtc:14852
Change-Id: I0f96ce1ed9be3aee2a702804612524676c9882fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291323
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39248}
relax DCHECK and explain when it previous version could be hit.
Use concise versions of the GetExtension functions.
Reduce scope of the `lock_`
Bug: None
Change-Id: Iafc570ffe7e5b2dcbdfe166b26b140f7959c28c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291711
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39246}
This seems to happen 2.5 seconds after initialization.
Written as part of debugging a different issue.
Bug: webrtc:13931
Change-Id: I3686cdbc39284505a437ebc0bfd8c74c483624c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291704
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39245}
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}
