Use speech content instead of white noise and enable target vs measured
bitrate tests.
Bug: webrtc:11360
Change-Id: If8c8e73f943eda14efeb22ba406c7a1bed7d32b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168660
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30630}
This cl add a configuration flag to allow REMB messages to be sent immediately when the bitrate value have changed.
The remb message is still included in all following compound packets.
Bug: None
Change-Id: I9f71d30cddbccd095e1d2971247c731bd1727d32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169221
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30627}
This reverts commit 49734dc0faa69616a58a1a95c7fc61a4610793cf.
Reason for revert: Still something wrong with ulpfec fuzzer setup.
Original change's description:
> Reland "Refactors UlpFec and FlexFec to use a common interface."
>
> This is a reland of 11af1d7444fd7438766b7bc52cbd64752d72e32e
>
> Original change's description:
> > Refactors UlpFec and FlexFec to use a common interface.
> >
> > The new VideoFecGenerator is now injected into RtpSenderVideo,
> > and generalizes the usage.
> > This also prepares for being able to genera FEC in the RTP egress
> > module.
> >
> > Bug: webrtc:11340
> > Change-Id: I8aa873129b2fb4131eb3399ee88f6ea2747155a3
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168347
> > Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> > Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#30515}
>
> Bug: webrtc:11340, chromium:1052323
> Change-Id: Id646047365f1c46cca9e6f3e8eefa5151207b4a0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168608
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30593}
TBR=sprang@webrtc.org,stefan@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:11340, chromium:1052323
Change-Id: I920ce0a48a08768d7a98a563e2b66bd6eb8602b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169121
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30616}
The fact that they weren't const is probably a remenant of the good ol'
days this class being multi-threaded and having to acquire mutexes. Now
they can properly be made const.
In order to make GetConstAdaptCounter() const, this CL makes sure a
cleared adapt_counters_ map contains mappings for all degradation
preferences to default-constructed AdaptCounters. Previously, if the
mapping was missing it was implicitly inserted by
GetConstAdaptCounter(). Now it can DCHECK that mappings always exists
instead, and it always has something to return.
Bug: webrtc:11222
Change-Id: If33227fe6572eb1d6cc6b9f851d6d174d035c110
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168953
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30611}
* This replaces the video stream methods for forcing adaptation
with a mock resource that triggers overuse.
* Resources can now be injected to the Module using the AddResource
function.
* Resources now have tests for adding and removing callbacks.
* Quality/EncoderUse% resources are tracked in the Resource list of
the adaptation module.
* The adaptation module ties all resources to a reason to keep stats
working as expected.
BUG=webrtc:11377
Change-Id: I1f5902f7416dc41b4915c0072e6f0da2bb3bb2b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168948
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30610}
frame_id is unwraped from a 16bit value.
Getting to int64_t boundaries would take more than 2^48 packets.
That scenario considered unrealistic and thus untested.
Bug: chromium:1053482
Change-Id: Ib3f52d4528b20915b2330773f616d9304f45cac6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168682
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30607}
Today OnResourceOveruse() and OnResourceUnderuse() implicitly checks
preconditions and if they pass calculate the next target, and if those
are usable it applies them to the VideoSourceRestrictions. These are two
big "MaybeAdapt" methods.
This CL takes us one step closer to "GetNextTarget", "CanApplyTarget?"
and "DoApplyTarget!"-logic, which will allow us to more easily evaluate
a multitude of alternative configurations and decide which one to pick
(e.g. multi-stream adaptation).
But it does not take us all the way there. In this CL we have:
- CanAdaptUp, CanAdaptDown: This covers *most* of the preconditions.
- OnResourceUnderuse, OnResourceOveruse: This aborts if CanAdapt returns
false. If they pass, we calculate the next target and maybe-adapt it.
This is roughly outlined in document still in draft:
https://docs.google.com/document/d/1YMg-AycFZR1DS6hEav9OzJ3hqxFil09qPhlTAgQrU1g/edit?usp=sharing.
A future CL should make the target more explicit and we should know if
the target can be applied before we even try.
Bug: webrtc:11222
Change-Id: If18d9572884aa6ba2350e4670a1516da5835cc98
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168721
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30605}
Elapsed time since last played out frame could be incorrect in GetCurrentEstimatedPlayoutNtpTimestampMs (e.g. if playout stops).
Bug: webrtc:7065
Change-Id: Ibb40b153ea7291e2cd3843c71ab44ff0fb00971c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168720
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30604}
DefaultVideoQualityAnalyzer accumulates in flight frames in internal
queue to perform psnr/ssim computation. This queue can grow a lot if
test experience high frame loss. As a result of this, the analyzer
can use quite a lot of memory and cause OOM crashes.
This CL limits the size of the queue based on the assumption that after
a certain point a frame can be considered lost and so it is impossible
to calculate PSNR/SSIM.
Bug: webrtc:11373
Change-Id: Iaabcc8d1c3c9142dc58ea5f2f30f599864b088e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168951
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30602}
Adapting up or down is currently a "Maybe Adapt" method. In the future
we will want to be able to decide which stream to adapt, and as such we
need to be able to tell if a stream is able to do so.
This takes us one step in that direction, by refactoring
OveruseFrameDetectorResourceAdaptationModule::VideoSourceRestrictor's
methods to follow a simple pattern:
- What is the next step?
GetHigherFrameRateThan, GetLowerFrameRateThan,
GetHigherResolutionThan, GetLowerResolutionThan
- Can we adapt?
CanIncreaseFrameRate, CanDecreaseFrameRate,
CanIncreaseResolution, CanDecreaseResolution
- Do adapt!
IncreaseFrameRateTo, DecreaseFrameRateTo,
IncreaseResolutionTo, DecreaseResolutionTo
Hopefully this makes the code easier to follow.
This CL changes the "Request Higher/Lower" methods to take the target
as input instead of implicitly calculating the target from the current
input resolution or frame rate.
Bug: webrtc:11222
Change-Id: If625834e921a24a872145105f5d553fb8f9f1795
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168966
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30600}
This is the WebRTC equivalent of testing/perf/perf_result_reporter.h
in Chromium. That class was introduced because the PrintResult
functions are quite hard to use right. It was easy to mix up
metrics, modifiers and stories, for instance.
I choose to introduce this new class because I need to create a new
API for PrintResult anyway. For instance, the important bool isn't
really supported by histograms. Also I would like to restrict units
to an enum because you cannot make up your own units anymore.
We could also have had a strictly checked string type, but that's
bad API design. An enum is better because the compiler will check
that the unit is valid rather than at runtime.
Furthermore, down the line we can probably make each reporter write
protos directly to /tmp and merge them later, instead of having a
singleton which writes results at the end and keeps all test results
in memory. This abstraction makes it easy to make a clean and simple
implementation of just that.
Steps:
1) land this
2) start rewriting perf tests to use this class
3) nuke PrintResult functions
4) don't convert units to string, convert directly from Unit
to proto::Unit
5) write protos directly from this class (either through
a singleton or directly) and nuke the perf results writer
abstraction.
Bug: chromium:1029452
Change-Id: Ia919c371a69309130c797fdf01ae5bd64345ab2e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168770
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30599}
Loosen the restrictions for ice-char by also allowing
'#' (known to break) and '_' (urlsafe base64) in addition
to the existing exceptions for '-' and '='.
Also fixes typo in log message.
BUG=chromium:1053756
Change-Id: I8f254a7c25f780276452fa3e27245b6b7ad1a3ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168943
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30596}
This is a reland of 11af1d7444fd7438766b7bc52cbd64752d72e32e
Original change's description:
> Refactors UlpFec and FlexFec to use a common interface.
>
> The new VideoFecGenerator is now injected into RtpSenderVideo,
> and generalizes the usage.
> This also prepares for being able to genera FEC in the RTP egress
> module.
>
> Bug: webrtc:11340
> Change-Id: I8aa873129b2fb4131eb3399ee88f6ea2747155a3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168347
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30515}
Bug: webrtc:11340, chromium:1052323
Change-Id: Id646047365f1c46cca9e6f3e8eefa5151207b4a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168608
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30593}
This CL refactors and optimizes the 3-band split-filter in APM, which
is a very computationally complex component.
Beyond optimizing the code, the filter coefficients are also quantized
to avoid denormals.
The changes reduces the complexity of the split filter by about 30-50%.
The CL has been tested for bitexactness on a number of aecdump
recordings.
(the CL also removes the now unused code for the sparse_fir_filter)
Bug: webrtc:6181
Change-Id: If45f8d1f189c6812ccb03721156c77eb68181211
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168189
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30592}
I think these functions are so hard to understand, so I tried to
make an as grounded example as possible.
Bug: chromium:1029452
Change-Id: I5d4284bc15b39cb94ba42d2c483a619ecf42fb91
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168945
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30590}
This is a reland of 1a290e4495c8132e7ff2c44d78de5e1d7eefdb9e
after fixing the downstream projects.
Original change's description:
> Remove old-style OnFailure callbacks
>
> Also delete default implementation of new-style OnFailure,
> since it can't call the deprecated function.
>
> Deprecating the old-style OnFailure callback turned out to be impossible,
> since one can't have the new-style callback call the old-style one.
>
> Bug: chromium:589455
> Change-Id: Icf529ddb02d99ad9e205095d5a1fbeb0da91dd0e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146219
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30570}
Bug: chromium:589455
Change-Id: I7227e3c6886c504043b019b621e45658cbd6fd53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168941
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30583}
