Since the Perf tester is actually compiling histogram code, it needs
to have it's own native OS gclient and GN config. The Builder has already
built and cached the MacOS arm64 binaries to be tested for M1.
I got confused and thought the tester was also compiling something for
the bot it shards to.
Bug: b/232347569
Change-Id: I0468945a04905d2d647626229af77c00d1f632fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263200
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Christoffer Jansson <jansson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36969}
This change adds a Block class to reduce the need for std::vector<std::vector<std::vector<float>>>. This make the code
easier to read and less error prone.
It also enables future changes to the underlying data structure of a
block. For instance, the data of all bands and channels could be stored
in a single vector.
The change has been verified to be bit-exact.
Bug: webrtc:14089
Change-Id: Ied9a78124c0bbafe0e912017aef91f7c311de2ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262252
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36968}
GCP permissions have also been updated to allow
bigquery dataset and table read+create etc.
Bug: b/227310186
Change-Id: I2e0404877b608c1b3dd9bb3d97fa99f712832a1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263160
Commit-Queue: Christoffer Jansson <jansson@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36967}
This CL adds a parameter to include `TRACE_DISABLED_BY_DEFAULT`
categories for internal usage. Tentatively set it by default.
Bug: webrtc:14080
Change-Id: I62a1a437b8d144b86bc5017e20e2f35e042ad2cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260664
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36966}
In case the encoder TQ has been stopped and doesn't accept more tasks,
we could end up in a hung state during Stop(). This is a hypothetical
situation, but can be simulated in a test and avoided.
Bug: webrtc:14063
Change-Id: I20f48b11b6266f6875ed5e69de3529212505e439
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258125
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36964}
This is part of the project to delete the class entirely.
The CL also adds an "use_rtx" parameter to the function for listing
video codecs, rather than filtering those away afterwards.
Bug: webrtc:13931
Change-Id: I96b9b18c694a1c0986ccf22face76ef4c704d372
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262666
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36963}
Step one in making it a separate type, that will be done as a
followup, after downstream code is updated to use the new name.
Bug: webrtc:11607
Change-Id: I6fa664a0729b1cfd71b7f02b6441880beee0e741
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262806
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36946}
AcmReceiver basically only does resampling, which is not something we need to test for bit-exactness.
NetEq bit-exactness is already tested with the same rtp input file as these tests.
Bug: None
Change-Id: Ibb3936c86098e0eea944860d33e2c13bf046e40b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262816
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36944}
to make tests faster and more determenistic.
Bug: webrtc:8239
Change-Id: I18067251a1f1a349fda28bbfbb59bce333bfddca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/201737
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36938}
To make it usable in tests without depending on all of CallTest.
Bug: None
Change-Id: Ie3102ab71bcfe3862dd6c35d3285098e961e54df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262807
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36932}
This will be used as a fall-back when the encoder adapter doesn't
provide any dependency structure. This ensures we can always generate a
dependency descriptor RTP header extension for VP8.
Before, when switching between encoder adapters where the old one
generated a dependency structure but the new one didn't we had to make
sure the structure was cleared so that packets weren't sent with the
dependency structure from the previous adapter. This will not be a
problem anymore since the new adapter will use the simulated dependency
structure.
Bug: b/227749056
Change-Id: I8463c48a9dcde4b8d32c519819dd8a92acd8e43b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262765
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36930}
The perf builders have been moved from the 'ci' to the 'perf' bucket.
Bug: b/233159334
Change-Id: Ic5de4489892599d3a9cf94696a4db8a708c1f0e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262808
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36928}
This is a preparatory step in deleting the ChannelManager class.
Also delete some declarations whose implementation was previously removed.
Bug: webrtc:13931
Change-Id: I8764c00fa696932e79fcfe17550ef2490d6a1ed1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262804
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36923}
implements a total frame assembly time statistic that measures the
cumulative time between the arrival of the first packet of a frame
(the lowest reception time) and the time all packets of the frame have
been received (i.e. the highest reception time)
This is similar to totalProcessingDelay
https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-totalprocessingdelay
in particular with respect to only being incremented for frames that are being decoded but does not include the amount of time spent decoding the frame.
This statistic is useful for evaluating mechanisms like NACK and FEC
and gives some insight into the behavior of the pacer sending the
packets.
Note that for frames with just a single packet the assembly time will be zero. In order to calculate an average assembly time an additional frames_assembled_from_multiple_packets counter for frames with more than a single packet is added.
Currently this is a nonstandard stat so will only show up in webrtc-internals and not in getStats. Formally it can be defined as
totalAssemblyTime of type double
Only exists for video. The sum of the time, in seconds, each video frame takes from the time the first RTP packet is received (reception timestamp) and to the time the last RTP packet of a frame is received.
Given the complexities involved, the time of arrival or the reception timestamp is measured as close to the network layer as possible.
This metric is not incremented for frames that are not decoded, i.e., framesDropped, partialFramesLost or frames that fail decoding for other reasons (if any). Only incremented for frames consisting of more than one RTP packet. The average frame assembly time can be calculated by dividing the totalAssemblyTime with framesAssembledFromMultiplePacket.
framesAssembledFromMultiplePacket of type unsigned long
Only exists for video. It represents the total number of frames correctly decoded for this RTP stream that consist of more than one RTP packet.
For such frames the totalAssemblyTime is incremented.
BUG=webrtc:13986
Change-Id: Ie0ae431d72a57a0001c3240daba8eda35955f04e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260920
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36922}
(Support parsing TWCC which nack sequnce numbers greater than the last
one received. Don't silently drop unrecognized/malformed RTCP packets.)
Bug: webrtc:14078
Change-Id: I34a0deabfdb5f36b988919cfcc9159197435756c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262800
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36921}
for video dealing with both the case where there is no common media
codec as well as only a red/ulpfec/flexfec codec in common for video
and only RED/CN in common for audio
BUG=webrtc:4957,webrtc:14069
Change-Id: I1c888b4f77199aade8122051c31b690dc2fd5925
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262642
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36920}
