One should use a std::unique_ptr to the object, as returned
by Clone() instead, not a naked pointer.
Bug: webrtc:10701
Change-Id: I10ab309207f2cb5aec83a6d09336699ed7b26f50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169342
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30646}
Without exposing it in capabilities:
this extension is not stable enough to expose it by default,
but already in working state so with munge sdp can be experimented with.
Bug: webrtc:10342
Change-Id: I6bac123325a90431e4769e86da79638869e36cfc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168961
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30645}
This CL takes us one step closer to being able to evaluate alternative
possible adaptation targets (e.g. multi-stream adaptation) by exposing
the target separately from applying it.
This is a refactoring of OnResourceUnderuse() and OnResourceOveruse().
Prior to this CL, the target resolution or frame rate was calculated
inside these methods and applied if possible. This CLs makes these two
steps (calculating a usable target + applying it) separate methods.
After this CL, the target is expressed as AdaptationTarget and is
calculated and returned by GetAdaptUpTarget() and GetAdaptDownTarget().
The target is only returned if it can be applied - and CanAdaptUp() +
CanAdaptDown() are merged with these methods.
Applying the target happens at ApplyAdaptationTarget().
Bug: webrtc:11222
Change-Id: I8e488be1d1590c23848db816d49a7738562e176d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169100
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@{#30643}
Move FuzzAudioEncoder to a separate target to make it available for
other encoders.
Bug: webrtc:11388
Change-Id: I8b9a0f810791880eedb129b55eb33f154790e48f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169364
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30634}
This makes it easier to reuse existing audio network adaptation
configurations in the scenario framework.
Bug: webrtc:9510
Change-Id: I06ab08684d449fef7fffe265d1078738d526a43d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169363
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30633}
This makes slightly more sense when looking at video resolution etc.
Bug: webrtc:9510
Change-Id: I49d39cac23d2f5d7ca09f2a27152c7519ea639f1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169344
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30632}
That would allow to switch components from relying on ProcessThreads to
relying on TaskQueue one by one, without introducing new threads.
Bug: webrtc:6289
Change-Id: I18fe5d679d4d4d0ddf4a11900c9814eb570284d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167533
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30631}
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}
