This allows callers to modify an encoded video frame's SSRC via the
setMetadata() call, which we'd like to do from Chrome, to allow using
an encoded frame from one PC on a different one.
Bug: webrtc:14709
Change-Id: Ia6b33761a3f63038f6eabbcd848916877e24454b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292380
Auto-Submit: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39266}
Absolute capture time extension did not work in tests that use test_audio_device. This change add capture timestamp to test audio device so absolute capture timestamp extensions can be sent in tests.
This make it possible to write tests for absolute header extension in Hamrit, and possible other test platforms as well.
Bug: None
Change-Id: Ie237f516ce0cccf43c32fe40da76a9d31f9fba53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292340
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39265}
addressing feedback from
https://github.com/w3c/webrtc-extensions/issues/130
and aligning the behavior with setCodecPreferences.
BUG=chromium:1051821
Change-Id: If0c29e1e16781b6898814e2f888ad08a079fc609
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/286780
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39264}
Also added an enum for unknown reason.
New value uses a macro-like name rather than a constant-like name for consistency.
Bug: chromium:1369096, webrtc:14131
Change-Id: Ib315584ec40d8c1cd9a6f0ff44587c0d92c735d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292341
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#39262}
This verifies that receiving two RTCP SR packets is enough to get
a defined capture start time stat.
Bug: webrtc:13931
Change-Id: Ib5f7c2954eab6500917f25c44f523d3aedae5e94
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291520
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39261}
This records high level errors, or success, encountered across the entire capture flow in the DXGI based capturer.
Using the same style as for WebRTC.DesktopCapture.Win.WgcCapturerResult
Bug: chromium:1400204
Change-Id: I7096d1790d7c2a23bbe29761b7dbf40426ce1e6a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291707
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39259}
Passing of ownership of codecs to tester is not strictly needed. We may need to continue using a codec after test. For example, to check codec state or to use the same codec instance in next test.
Bug: b/261160916, webrtc:14852
Change-Id: I179b262116d7de76b8171f0409f943ad6d87433e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291802
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39256}
Step 1 of combining the sender and receiver types
Also moved the RtpFrameObject to rtp_rtcp/source, as it's heavily used
by the transformable receiver frame, I couldn't work out a better way
of managing the dependencies, and everything else seemed to work fine.
Bug: chromium:1412687
Change-Id: I55e816a0d7aa2962560ff9ebaf30ad63ab0b9810
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291710
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#39255}
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}
