This check was added here:
https://webrtc-review.googlesource.com/c/src/+/300544
When createOffer is used before createAnswer, this check would cause
SetupDataChannelTransport_n to not be called for the remote channel.
Bug: webrtc:15258
Change-Id: Ifdab35d1b0260ff03fef4beff13acf8090d59d8f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310460
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40357}
We haven't switched to the std spelling in WebRTC yet.
Change-Id: If21a6ee9ac19be8ce959b3192eb8de044048f157
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310501
Auto-Submit: Emil Lundmark <lndmrk@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40356}
under the same conditions as video_replay.
Drive-by: fix typos
BUG=webrtc:15210
Change-Id: I6d288b2f7c8e2101192556eada6b28c82bfabf2f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308723
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40355}
Removes the top 3 filtering based on frame energy. This behaviour is
unexpected for many application developers and the platform should not
have such arbitrary limitations. Developers can still implement top-N
filtering using WebAudio or an SFU (recommended to increase
scalability).
Performance is not really a concern in this case since decoders on all
receive streams are called regardless if they are mixed or not
(assuming packets are received).
This also fixes glitches caused by the current implementation since
sources are not ramped out.
Bug: chromium:1446655,webrtc:13818
Change-Id: I179a6d68d2517b94ff2d99ec269031a54e5099e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310180
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40349}
The test fails with the new AV1 roll and it looks like it is a test
issue. Skipping the test to allow the roll to flow, the test will be
re-enabled later.
Bug: b/288825767
Change-Id: I1ae5aab6860b6b4ac82a3e1b37619551aa2fba53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310421
Reviewed-by: Jerome Jiang <jianj@google.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40348}
to ensure consistency for both FID and FEC-FR ssrc-groups.
BUG=chromium:1454860
Change-Id: I61277e73e0a28f5773260ec62c268bdc8c2cd738
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309760
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40347}
Instead switch to specific getters, or methods only defined on specific implementations rather than part of the public API.
Once uses are removed from Chromium, I'll mark GetHeader() deprecated
and eventually remove it.
Bug: chromium:1456628
Change-Id: I19b80489b3a0322c201e24994494cfbb742ee13e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309780
Commit-Queue: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40344}
This needs to be rolled back as soon as the deprecated declarations
diagnostic errors get fixed.
Bug: b/288827308
Change-Id: I9584e0f156b0bd0ba40809d43e1edd7ba9ff5674
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310300
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40342}
This flag is no longer used in Chrome and can now be removed.
Bug: chromium:1314868
Change-Id: Id91b3352dc7ec0543d54894cc206a6e0c7667e9e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309960
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40337}
This annotates all unannotated members in VideoCaptureImpl and its
subclasses with either of:
- api_checker_: access on the api thread only
- capture_checker_: access in callbacks/on the capture thread while
capture is active, on the api thread otherwise
- a Mutex if it is already protected by it
Bug: webrtc:15181
Change-Id: I5084e7752a4716c29b85a9b403a88696f66d811f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305647
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40335}
which means this will not show up in getStats inbound-rtp/outbound-rtp
until the encoder/decoder is known. This has implications in particular
for inbound-rtp where the value is currently "unknown" until video
frames have been received.
This is safe to change as the previous change to gate
decoderImplementation behind getUserMedia access already broke
the assumption that the field is always string.
BUG=webrtc:14906
Change-Id: Ie6040ada3656e80f792c0c32c1b86ad1d6609d3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293600
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40334}
filtering out the -1 value as it is done for "legacy" stats.
Also change the protocol and don't use "udp" and "tcp" which are misleading since the datachannel protocol is user-supplied.
BUG=webrtc:15071
Change-Id: I45d735fcf30144969630f5b8a91b40f12585bbfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300483
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@{#40333}
This CL allows the users to now enable/disable WGC capturing support
for Window and Screen sharing independently.
Bug: chromium:1314868
Change-Id: Ieeb15539434dac2caf29c515aa7c5dbb7abcc5df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309560
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40330}
Media*Channel objects used to subclass webrtc::Transport.
This was not an optimal design. This CL makes the transport
a member variable of MediaChannelUtil.
Bug: None
Change-Id: I85d33cc1b32b931e563b7bb2d277f1c512600831
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309800
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40328}
This feature has had positive impact in downstream experiments, so we should enable it by default. It will be kept around as a kill switch for a while though.
Bug: webrtc:15260
Change-Id: Ibfd25f5be124f65cd4360ae76f7022bb46f65301
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309781
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40327}
specified in https://github.com/w3c/webrtc-stats/pull/762
and take FlexFEC into account for receive statistics.
BUG=webrtc:15250
Change-Id: Id85775ab1f29487d5b8bf478da6e22071005901a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294881
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40325}
Scoped enums do not get automatically promoted to their underlying type,
so these uses have undefined behavior and Clang recently started warning
about it.
Bug: chromium:1456289
Change-Id: I9cf4e5a68378930a3bf7d8ac7b0a21eaf0d12670
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309520
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Auto-Submit: Hans Wennborg <hans@chromium.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40321}
As before, events are processed primarily in timestamp order.
This CL adds a heuristic to break ties for events with the same timestamp.
- Roughly speaking, configs and connectivity events are processed first, followed by incoming packets, then BWE updates, then other (general) events and finally outgoing packets and ALR events.
- Among RTP packets, transport sequence number is used to break ties.
- The insertion order (into the EventProcessor) is used as a last resort.
Bug: b/282153758
Change-Id: I914e4500ca63e1a8754766d1833a7b32f6a38176
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308140
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40318}
[RTCIceCandidate initWithNativeCandidate:] does not take ownership on
candidate, so it must be released by caller.
Bug: None
Change-Id: I516e740e81a7aec04556f5fa71cbbecf3be6deb7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308500
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40314}
Referencing this type directly is not allowed when building
with the macOS 14.0 SDK.
Other usages in webrtc follow this inline pattern too so
going with this instead of "auto" which also works.
Change-Id: I84a0ba9c78e83843bc73c71c642caca75750f127
Bug: chromium:1454356
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308560
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40313}
This groups functions for WebRtcVideoSendChannel and
WebRtcVideoReceiveChannel together, rather than interspersing them.
Bug: webrtc:13931
Change-Id: Iecb5bac18e1d370331e9eb546c6b2fde4d92963f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309460
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40312}
Introduces a field trial
WebRTC-IncreaseIceCandidatePriorityHostSrflx
that adjusts the priority of non-relay candidates such that the STUN priority attribute calculated as
(prflx-type-preference << 24) | (priority & 0x00FFFFFF)
as described in
https://www.rfc-editor.org/rfc/rfc5245#section-7.1.2.1
will satisfy the condition that the STUN priority of server-reflexive candidates will always be higher than the STUN priority of relay candidates.
Previously this was not the case because the TURN relay preference was added to the local_preference for relay candidates, making it higher than the local_preference of srflx candidates gathered from the same interface.
This led to cases where the resulting candidate pair priority of a srflx-relay pair was higher than the candidate pair priority of a srflx-srflx pair, i.e. using a TURN server in cases that work using a direct P2P connection.
Whether the field trial is active can be observed by checking that
priority-of-srflx-candidate&0x00FFFFFF
is greater than
priority-of-relay-candidate&0x00FFFFFF
BUG=webrtc:13195,webrtc:5813,webrtc:15020
Change-Id: Ib91708fbe7310b6454f93158a45c9d77da009091
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292700
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40311}
