For all intent and purposes, it's a third party crate, and we don't deny
warnings in third party crates. It happens with mio 0.6 because we're
patching it to use winapi 0.3 and miow 0.3.
We also revert some older changes, to reduce the number of changes
against the canonical 0.6.23.
Differential Revision: https://phabricator.services.mozilla.com/D197026
Upstream commit: https://webrtc.googlesource.com/src/+/5f78ed6eafa40451b61747978d134afda42ca4d6
Minor change in comment for use of an IGraphicsCaptureSession3 API
Makes it more clear that a certain API is only supported in Windows 11.
Bug: webrtc:15451
Change-Id: Ic3abfb2cbf0e30f9cb722ac843876f41279bf200
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323161
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40931}
Upstream commit: https://webrtc.googlesource.com/src/+/52bc9f7c1205f4b731ea0289b059f7d240c1e228
[Merge M119] Return error when requested codec is preferred but not negotiated
Because of our asymmetrical codec situation, it's possible to have
send only codecs that we cannot negotiate even with ourselves.
This means that we should not have a DCHECK, but just a plain error.
(cherry picked from commit 1adea9806d7aec9b5f91181231ccc31fef3b115f)
Bug: chromium:1442194, webrtc:15064
Change-Id: I0c170e5c7f356197bcb04bcecb8259c344423ccb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323183
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#40939}
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324044
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/branch-heads/6045@{#2}
Cr-Branched-From: bce7ce7ba054ac0e79fed49b84ef52fb24c31778-refs/heads/main@{#40854}
Upstream commit: https://webrtc.googlesource.com/src/+/71e3fbf5d750e84d181315a663eb5dbc29a5330c
[M119 merge] Reland "Add mitigation for very long frame drop gaps with vp8"
This is a reland of commit 0d4b350006eae7dfeeb8c67f16f51b1c62351cee
Patchset 1 is the original CL. Patchset 2 contains a small tweak of the target bitrate in the unit test, in order to make in less susceptible to flakiness on runtime environments running a slightly different libvpx.
Original change's description:
> Add mitigation for very long frame drop gaps with vp8
>
> Bug: webrtc:15530
> Change-Id: I11f5e3f31f71301700dbff3fc9285236160bee45
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322320
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Auto-Submit: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#40866}
(cherry picked from commit d7703d950536473627533ed6eab24c2d50054e70)
Bug: webrtc:15530
Change-Id: I096b7d952286f7f53852d1ca70aea398b2747784
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322540
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#40874}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322900
Cr-Commit-Position: refs/branch-heads/6045@{#1}
Cr-Branched-From: bce7ce7ba054ac0e79fed49b84ef52fb24c31778-refs/heads/main@{#40854}
Upstream commit: https://webrtc.googlesource.com/src/+/bce7ce7ba054ac0e79fed49b84ef52fb24c31778
Adds support for tracking OnFrame PostTask delta times
Does not change any functionality but improves the ability to look
for (using Perfetto) possible latency issues where a posted task might
be prevented from running.
Bug: webrtc:15456
Change-Id: I522599c646c8de2183074628df9cab337b1cb85d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322121
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40854}
Upstream commit: https://webrtc.googlesource.com/src/+/dd15070b4539d49ae5e135e7d12b64bbc7bafb27
Adopt EglThread in EglRenderer once again.
The regression obseverved on Samung devices the last time was caused
by the not detaching the context/surface prior to releasing an
EGLSurface or EGLContext. This was fine on most devices but obviously
not all.
Bug: b/225229697
Change-Id: I1849c772f3ed3e8819c748d997e5261289c4b2bc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321842
Commit-Queue: Linus Nilsson <lnilsson@webrtc.org>
Reviewed-by: Zoé Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40844}
Essentially a no-op since we're going to see this change
reverted when we vendor in c27034b694.
Upstream commit: https://webrtc.googlesource.com/src/+/a2f30e1a7508c25c1402ee756b8fe948cbb53e7c
Expose getCapabilities/setCodecPreferences for objc
Bug: None
Change-Id: I31cf22bae595cf2b995ff648523d25485106fcd5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305200
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
Commit-Queue: Peter Hanspers <peterhanspers@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40841}
Upstream commit: https://webrtc.googlesource.com/src/+/34ec5c3f20a69c7d255076f75b3cebceb8557676
Clear PacketBuffer on large negative jumps at the start of the video stream
PacketBuffer is not designed to store wide range of the rtp sequence numbers
Bug: webrtc:15508
Change-Id: I62b19ba2896a667d795a41c38a60f55ee3f60566
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321845
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@google.com>
Cr-Commit-Position: refs/heads/main@{#40839}
Upstream commit: https://webrtc.googlesource.com/src/+/e9f9c28d484ee555e52f9412b1b30e5b254f2a8f
Set permissions on experiments/field_trials.py
Since the previous policy was "anyone can add one", we're allowing
anyone to update this file for the time being.
Bug: webrtc:14154
Change-Id: Ib979797044f5eef014dce427ba6ad98837a98b46
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321960
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40838}
Upstream commit: https://webrtc.googlesource.com/src/+/a61b334a12c7556c64887e1c553fd822d060881d
Relax the field trial policy to not require an open bug
Having an associated bug with an owner should be sufficient information
for determining the status of a field trial. See the discussion starting
at [1] for more context.
[1] https://crbug.com/webrtc/14154#c11
Bug: webrtc:14154
No-Try: true
Change-Id: I7054ba25eac2af852a0d08770037938571e38921
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321862
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40837}
Upstream commit: https://webrtc.googlesource.com/src/+/5e252b7fa590c59f60697ece8a9445140e1f5cb4
Register WebRTC-Bwe-SubtractAdditionalBackoffTerm
It was introduced with 98e71f57eaa9 ("Subtract an additional 5kbps of
the bitrate when backing off.").
Bug: webrtc:13402
Change-Id: Icf8c633fa5086ac1f854a112d8eaeaf47d1ae211
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321844
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Auto-Submit: Emil Lundmark <lndmrk@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40836}
Upstream commit: https://webrtc.googlesource.com/src/+/a93f581705787105ac28bccdc179778fd4400298
dcsctp: Don't generate FORWARD-TSN across stream resets
This was a fun bug which proved to be challenging to find a good
solution for. The issue comes from the combination of partial
reliability and stream resetting, which are covered in different RFCs,
and where they don't refer to each other...
Stream resetting (RFC 6525) is used in WebRTC for closing a Data
Channel, and is done by signaling to the receiver that the stream
sequence number (SSN) should be set to zero (0) at some time. Partial
reliability (RFC 3758) - and expiring messages that will not be
retransmitted - is done by signaling that the SSN should be set to a
certain value at a certain TSN, as the messages up until the provided
SSN are not to be expected to be sent again.
As these two functionalities both work by signaling to the receiver
what the next expected SSN should be, they need to do it correctly not
to overwrite each others' intent. And here was the bug. An example
scenario where this caused issues, where we are Z (the receiver),
getting packets from the sender (A):
5 A->Z DATA (TSN=30, B, SID=2, SSN=0)
6 Z->A SACK (Ack=30)
7 A->Z DATA (TSN=31, E, SID=2, SSN=0)
8 A->Z RE_CONFIG (REQ=30, TSN=31, SID=2)
9 Z->A RE_CONFIG (RESP=30, Performed)
10 Z->A SACK (Ack=31)
11 A->Z DATA (TSN=32, SID=1)
12 A->Z FORWARD_TSN (TSN=32, SID=2, SSN=0)
Let's assume that the path Z->A had packet loss and A never really
received our responses (#6, #9, #10) in time.
At #5, Z receives a DATA fragment, which it acks, and at #7 the end of
that message. The stream is then reset (#8) which it signals that it
was performed (#9) and acked (#10), and data on another stream (2) was
received (#11). Since A hasn't received any ACKS yet, and those chunks
on SID=2 all expired, A sends a FORWARD-TSN saying that "Skip to TSN=32,
and don't expect SID=2, SSN=0". That makes the receiver expect the SSN
on SID=2 to be SSN=1 next time at TSN=32.
But that's not good at all - A reset the stream at #8 and will want to
send the next message on SID=2 using SSN=0 - not 1. The FORWARD-TSN
clearly can't have a TSN that is beyond the stream reset TSN for that
stream.
This is just one example - combining stream resetting and partial
reliability, together with a lossy network, and different variants of
this can occur, which results in the receiver possibly not delivering
packets because it expects a different SSN than the one the sender is
later using.
So this CL adds "breakpoints" to how far a FORWARD-TSN can stretch. It
will simply not cross any Stream Reset last assigned TSNs, and only when
a receiver has acked that all TSNs up till the Stream Reset last
assigned TSN has been received, it will proceed expiring chunks after
that.
Bug: webrtc:14600
Change-Id: Ibae8c9308f5dfe8d734377d42cce653e69e95731
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321600
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40829}
Essentially a no-op since we're going to see this change
reverted when we vendor in c2bbe4b952.
Upstream commit: https://webrtc.googlesource.com/src/+/d8633868b34dc1d841f0a9fd1afe2bc22aa8bde6
Enable SRTP GCM ciphers by default
Bug: webrtc:15178
Change-Id: I0216ce8f194fffc820723d82b9c04a76573c2f4f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305381
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40828}
Upstream commit: https://webrtc.googlesource.com/src/+/98e71f57eaa94dc085e712d939c19c0bf57b9b37
Subtract an additional 5kbps of the bitrate when backing off.
Traditionally, we'd back off to 85% of the measured throughput in response to an overuse. However, this backoff doesn't appear to be sufficient to drain the queues in some low-bitrate scenarios, and the problem has gotten a bit worse with the RobustThroughputEstimator. (The new estimate looks more stable. The old estimator had more variation, the lowest points were lower, causing backoffs to lower rates.)
With this change, we back off to 0.85*thoughput-5kbps. The difference is negligible except at low bitrates.
Bug: webrtc:13402,b/298636540
Change-Id: I53328953c056b8ad77f6c7561d6017f171b2dfbc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321701
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40827}
