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}
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}
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}
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}
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}
and clean up methods that are now detected as unused.
BUG=None
Change-Id: If5dac3d43d4df6c7c108504c202c2383fe4a3f27
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321580
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40823}
Since the registry now also stores the end date, the bug doesn't have to
specify this.
Bug: webrtc:14154
Change-Id: I94dee43105079607ff9d820e238018304eb441a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321582
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40821}
Speculative fix. Writing the test for it is more complex.
Bug: chromium:1483874
Change-Id: Icfaf1524b0499c609010753e0b6f3cadbd0e98f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321480
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40820}
The lists has been constructed by grepping the code base from commit
bfc2a3553d56 ("Remove more codec-related templating") using the PCRE
'(?<=")WebRTC-[^\s/"]+' and manually removing some false positives. Each
field trials has then, on a best effort basis, been associated with a
bug by doing a reverse git log lookup and using the corresponding bug
tag that was associated with the commit where the field trial key was
first introduced.
The field trials are divided into active and policy exempt. The latter
are for field trials that were added before commit c4a35898d916 ("Add
documentation for field trials") which introduced the new policy that
field trials henceforth needs to be registered. These field trials may
not have an associated bug nor an end date.
For all field trials that have been deemed experimentational, including
many policy exempt ones, an initial end date of 2024-04-01 has been
chosen. This date was chosen based on that the policy was introduced on
2022-06-23 and will give about 6 month grace period to allow cleanup of
potentially already expired field trials. Owners are of course free to
adjust the end date at a later time.
The lists have been validated by running most tests with the following
GN arg set:
rtc_strict_field_trials = "dcheck"
Bug: webrtc:14154
Change-Id: Ic86d96933fbe0f18393ec57d36719a382855c694
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321581
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40819}
This change replaces type of absolute_capture_timestamp_ms_ in
TransformableOutgoingAudioFrame from int to optional uint and makes
the function AbsoluteCaptureTimestamp() inside
TransformableAudioFrameInterface pure virtual.
Bug: webrtc:14949
Change-Id: Id3bdbcba63a5f91105ab198208e4f2b11eb3c7db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319000
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40814}
https://datatracker.ietf.org/doc/html/rfc6525#section-5.2.2:
E2: If the Sender's Last Assigned TSN is greater than the cumulative
acknowledgment point, then the endpoint MUST enter "deferred
reset processing". ... until the cumulative
acknowledgment point reaches the Sender's Last Assigned TSN.
The cumulative acknowledgement point can not only be reached by
receiving DATA chunks, but also by receiving a FORWARD-TSN that
instructs the receiver to skip them. This was only done for DATA and not
for FORWARD-TSN, which is now corrected.
Additionally, an unnecessary implicit sending of SACK after having
received FORWARD-TSN was removed as this is done anyway every time a
packet has been received. This unifies the processing of DATA and
FORWARD-TSN more.
Bug: webrtc:14600
Change-Id: If797d3c46e741074fe05e322d0aebec765a87968
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321400
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40811}
More general matches that can be reused, less specialized ones.
Bug: None
Change-Id: I12ea98caf4f566168566173a509c204bd25e5a13
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321123
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40804}
making the UsedId generator the source of truth.
BUG=webrtc:12197
Change-Id: I4318a1366f8b2e20ea5ae264232437a9006c5103
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321120
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@{#40802}
To avoid name collision with Timestamp type,
To avoid confusion with capture time represented as Timestamp
Bug: webrtc:9378
Change-Id: I8438a9cf4316e5f81d98c2af9dc9454c21c78e70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320601
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40796}
NSApplicationActivateIgnoringOtherApps is about to be deprecated.
The default behavior is good enough.
Tested on Chrome using https://wicg.github.io/conditional-focus/demo/
Bug: webrtc:15511
Change-Id: I1f59aea3d4e7c4942d17ee5c4f1b6c2d398016ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321080
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Auto-Submit: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40795}
The handover state has been added with
commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7.
This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366.
Bug: webrtc:14997
Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40794}
