Set 2 thread as target for 1280x720 pixel count, and then scale up
linearly from there - but cap at physical core count.
For common resolutions this results in:
1 for 360p
2 for 720p
4 for 1080p
8 for 1440p
18 for 4K
Bug: webrtc:11551
Change-Id: I666bd971eccddee096749f20d3b08eb40fe868ad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177012
Reviewed-by: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31513}
The side effect of not filtering on V4L2_CAP_VIDEO_CAPTURE is that
every device is enumerated twice. Because we look up devices by name,
and the device that supports V4L2_CAP_VIDEO_CAPTURE seems to always
appear first in /dev/video, this does not seem to end up with us ever
choosing an inappropriate device. We might get away with just filtering
device names from the list, but if the order of devices ever changed in
/dev/video there could be problems.
Bug: webrtc:11641
Change-Id: I16fee4edc873838ed4643ee16a8bbc699d6bbcf5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176460
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Dan Minor <dminor@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31508}
Previously, number of decoder threads for VP9 were always set to 8 but
with a cap at number of cores. This was done since we "can't know" the
resolution that will be used.
With this change, we now intialize the number of threads based on
resolution given in InitDecode(). If a resolution change happens in
flight, it requires a keyframe. We therefore parse the header from
any key frame and if it has a new resolution, we re-initialize the
decoder.
The number of threads used is based on pixel count. We set one thread
as target for 1280x720, and scale up lineraly from there. The 8-thread
cap is gone, but still limit it core count.
This means for instance: 1 <= 720p, 2 for 1080p, 4 for 1440p, 9 for 4K.
Bug: webrtc:11551
Change-Id: I14c169a6c651c50bd1b870c4b22bc4495c8448fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174460
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31507}
This unblocks injecting platform-specific resources, such as power
usage signals in Chrome.
This CL adds AddAdaptationResource to PeerConnectionInterface and
integration tests verifying that if an injected resource is overusing,
resolution will soon be reduced.
To aid testing, some testing-only classes have been updated.
Bug: webrtc:11525
Change-Id: I820099e79f18d910fd641ee1412ad064b99ebce9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177003
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31505}
This allows forcing a minimum frame rate if the producer doesn’t update
the SurfaceTexture often.
This needs to be done in SurfaceTextureHelper to keep the
synchronization of the texture access consistent.
Bug: b/149383039
Change-Id: I0e3c82dd51d486b931bd8dda0fd9d5cdb1a90901
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177001
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Xavier Lepaul <xalep@google.com>
Cr-Commit-Position: refs/heads/master@{#31504}
For stream sizes that were not multiple of 4, we could end up causing
a size_t wraparound which resulted in an infinite loop.
Bug: webrtc:9510
Change-Id: Ie3fe5345e1477efa6a4ec338bd9f9b00225e688e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177005
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31503}
This CL adds AddAdaptationResource to Call and
AddAdaptationResource/GetAdaptationResources method to relevant
VideoSendStream and VideoStreamEncoder interfaces and implementations.
Unittests are added to ensure that resources can be added to the Call
both before and after the creation of a VideoSendStream and that the
resources always gets added to the streams.
In a follow-up CL, we will continue to plumb the resources all the way
to PeerConnectionInterface, and an integration test will then be added
to ensure that injected resources are capable of triggering adaptation.
Bug: webrtc:11525
Change-Id: I499e9c23c3e359df943414d420b2e0ce2e9b2d56
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177002
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31499}
A more detailed explaination is in the bug, but this changes
the way that adaptation happens when multiple resources are
limited. Only the one that is most limited can trigger an
adaptation up. If multiple resources are most limited both
need to underuse to adapt up.
Some of the changes in this patch to make it all work:
* VideoStreamEncoder unittests that did not reflect this
new behaviour have been changed.
* PeekNextRestrictions returns the adaptation counters as
well as the restrictions.
* Adaptation statstics have changed so that when adapting
up all resources are tagged as triggering the adaptation.
Additionally the statistics for the current adaptation is
now the total number of adaptations per reason, rather then
the number of adaptations due to that reason.
* PreventAdaptUpDueToActiveCounts is removed as most limited
resource is a strong implementation of that.
Bug: webrtc:11553
Change-Id: If1545a201c8e019598edf82657a1befde8b05268
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176128
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31497}
Adding field trial WebRTC-Audio-NetEqExtraDelay with a parameter value
to set the extra delay in NetEq. This overrides the
extra_output_delay_ms parameter in NetEq::Config.
Bug: b/156734419
Change-Id: Iae7d439fafa3059494249959ac13a02de63d6b7a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176858
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31493}
This allows const getters that query const state to be called without
marshalling calls between threads. This must not be used to
return pointers/references etc.
I'm starting by using this macro with the data channel which has a
few of these getters, as well as changing things a bit to make more
parts of the implementation, const.
Change-Id: I6ec7a3774cd8f7be2ef122fb7c7fc5919afee600
Bug: webrtc:11547
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176846
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31489}
It may happen that if we have simulcast track with, let's say, 2 streams
A and B, we can receive frame X on A and then receive it again on B
when there is a switch from A to B. TO correctly handle it we need to
skip second receive of X. Later we need to add metric which will show
how many frames were in between when X was received twice.
Bug: webrtc:11557
Change-Id: I8c52a78674b62387f520a587f51e209ed7c0b0bc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176853
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31488}
It has been reported that sometimes FPS is undefined, causing the test
to be flaky.
Bug: webrtc:11651
Change-Id: Ieea33833724defa46110aad5d103aa16bfbea861
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176516
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31481}
for TaskQueueTest.
This suit is instantiated in the different binary targets by design.
Bug: None
Change-Id: I99a38e2461ee9bd06dfe68758490afe75c2475ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176750
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31476}
When using a SequenceChecker, this adds a bit more information
about why the check failed.
Example (The "Expects" line is new):
# Fatal error in: foo.cc, line 380
# last system error: 0
# Check failed: (&thread_checker_)->IsCurrent()
# Expects: System queue: 0x7fff69541330, TaskQueue: 0x101804370 (not current), Thread: 0x10053cdc0
Bug: none
Change-Id: I3743e1d80f369f15219de5946e9e081f998b9b17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176569
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31466}
Also removing some related code that appears to be unused.
This is a part of simplifying the RtpRtcpInterface implementation.
Bug: webrtc:11581
Change-Id: I580bfdc1b821d571cb7437d7713a49ee4de2d19a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176568
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31464}
