This CL is a minor cleanup of the work done earlier in [1].
We now remove the arguments which contained the measured delta times
between two TRACE_EVENT_ASYNC_BEGIN and TRACE_EVENT_ASYNC_END events.
Also, the ID for FrameToQueue1 is now unique which was not the case
previously.
The same information can be obtained from the `slice` table and the
`dur` key.
Also renames the events to OnFrameToEncode (total), OnFrameToQueue and
QueueToEncode to match what it measures better.
[1] https://webrtc-review.googlesource.com/c/src/+/322121
Bug: webrtc:15456
Change-Id: Ibe2d7bb53380710671c2c36012dcd573942bae69
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322220
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40860}
Similar to change I602a8552a9a4c853684fcf105309ec3d8073f2c2, which
ensured that only new DATA chunks would be processed by the reassembly
queue by utilizing the data tracker, the same is done for FORWARD-TSN
chunks.
By having the data tracker gate keeping what is provided to the
reassembly queue, the reassembly queue can be simplified as well, which
is an added bonus, by removing last_assembled_tsn_watermark_ and
reassembled_messages_ as those were protecting the queue from
re-delivering messages it had already delivered, but as now the data
tracker would ensure that it wouldn't re-process DATA/FORWARD-TSNs, that
would have the same effect. In this CL, we will still update those
variables and save to the handover state, but not actually read from
them, and then when this change has been rolled out on the servers, I
can remove the variables as well.
The core change is to move validation from ReassemblyQueue::Handle
to DataTracker::HandleForwardTsn.
Some tests have been moved/replicated into data_tracker_test.cc to
ensure that it catches the issues that the reassembly queue did earlier.
Bug: webrtc:14600
Change-Id: I75c1d5911185d594f73c8b1e6bcf776e88f5b7c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321603
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40856}
There's no trace of it being in use, so let's remove it.
Bug: webrtc:12497
Change-Id: I9e81ef58b459b5a0b9f79b6638231a3a19eb8a0e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322180
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Auto-Submit: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40855}
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}
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}
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}
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}
