This makes an assumption that if we have variable frame length then we
will increase payload bitrate up to priority bitrate before adapting the
frame length.
Bug: webrtc:11001
Change-Id: Iec51d5ccce053d55ccd30a9e4712765227e10852
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169852
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30713}
This fixes two cases when the allocation is not updated correctly:
- The frame length range is not updated when audio network adaptor is enabled.
- The per-packet overhead is not updated unless the bitrate observer has been reconfigured.
Bug: webrtc:11001
Change-Id: I2ee25f956741a4be08661f874556582dd60a3bd0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169848
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30709}
This CL moves GetAdaptUpTarget(), GetAdaptDownTarget() and
ApplyAdaptationTarget() - and related code - to the VideoStreamAdapter.
This includes pieces related to calculating how to adapt, including:
- DegradationPreference
- BalancedDegradationPreference
- AdaptationRequest and last_adaptation_request_
- CanAdaptUpResolution()
The VideoStreamAdapter's interface has changed: VideoSourceRestrictor
methods are now hidden in favor of methods exposing AdaptationTarget.
This CL also does some misc moves:
- GetEncoderBitrateLimits is moved and renamed to
VideoEncoder::EncoderInfo::GetEncoderBitrateLimitsForResolution.
- EncoderSettings moved to a separate file.
// For api/video_codecs/video_encoder.[cc/h] changes, which is the
// moving of a function.
TBR=sprang@webrtc.org
Bug: webrtc:11393
Change-Id: Ie6bd8ef644ce927d7eca6ab90a0a7bcace682f3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169842
Reviewed-by: Henrik Boström <hbos@webrtc.org>
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@{#30708}
This CL simply moves the VideoSourceRestrictor from being an inner class
of OveruseFrameDetectorResourceAdaptationModule to a new class,
VideoStreamAdapter.
In follow-up CLs, the responsibility of determining what the next step
for adapting up or down should also be moved to the VideoStreamAdapter.
The end-goal is that the VideoStreamAdapter takes care of "can adapt?"
and "do adapt!" type of logic so that a multi-stream aware adaptation
module can decide which stream (adapter) to adapt, and the adapter can
take care of the nitty gritty details of doing so.
In this CL the "can?"/"do!" part is realized but not the logic for
determining what the next step up or down is, and the class interface
needs improvement.
This CL also sets up the video/adaptation/ subdirectory and moves the
AdaptationCounters class here. Other adaptation-related classes (e.g.
the module and its resources) should move into this directory as well
in the future.
Bug: webrtc:11393
Change-Id: I2c12c1281eca854c62791abb65f0aca47a119726
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169542
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30705}
This changes removes an extra layer of indirection
since RtcpTransceiver doesn't own TaskQueue it uses.
Bug: None
Change-Id: Ie1ef4cd8c3fb18a8e0b7ddaf0d6a319392b9e9f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126040
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30704}
There is still a counter for the active counts for the
scaling, but these will be removed at a later date.
BUG=webrtc:11392
Change-Id: Ie9bcf3f744a0bbac601f0da61197f4bac1e9f879
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169447
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#30701}
Replayer isn't triggered in any pre- or post-submit checks
and is built only as a part of fuzzers. Therefore it got out of sync
with the requirement of Call::Config::trials being set.
Bug: chromium:1030755
Change-Id: I467a5fa19137020f6fc748b6adb6f82a8a88f9d1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169847
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30695}
The decision to route audio packets to a separate overuse detector
is off by default and requires the field trial
WebRTC-Bwe-SeparateAudioPackets/enabled,packet_threshold:10,time_threshold:1000ms/
The parameters control the threshold for switching over to the
audio overuse detector if we stop receiving feedback for video.
Bug: webrtc:10932
Change-Id: Icdde35bc7a98b18b1a344bd2d620a890fd9421d9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168342
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30694}
This fixes an issue where the delay based target bitrate would increase
unlimited when the WebRTC-DontIncreaseDelayBasedBweInAlr is set.
Bug: webrtc:10542
Change-Id: I1aaf0835a91efc27e95198812b6833dbc24a1485
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169843
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30693}
It can only be one of four possible values, so it never made sense
for it to be a double. Other than the fact that its neighbor
bitrate_priority is a double, and they're both defined as the same enum
in the web spec. However, while bitrate_priority being a double
offers more flexibility than the web spec, network_priority being a
double is only confusing.
Bug: webrtc:5658
Change-Id: I0784c116f3260c4b3a8b99a3cd85c8d66017e46f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168840
Reviewed-by: Anders Carlsson <andersc@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30685}
Adding :: before rtc allow us to use the macro in nested rtc namespace for external components like
namespace xxxxxxx {
namespace rtc {
RTC_CHECK(true);
}
}
Bug: webrtc:11400
Change-Id: I79349b847c3fce8197c82aec31b672a1a16e5388
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169683
Commit-Queue: Jiawei Ou <ouj@fb.com>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30684}
Also, make sure active flags are not lost in simulcast encoder adapter
which is needed in case of simulcast encoder adapter is used.
VP9 libvpx encoder currently ignores scaling setting for SVC, but libvpx
fix is incoming.
TESTED=On a manually patched chrome with singlecast-simulcast vp8 stream.
Bug: webrtc:11396
Change-Id: Ic81f014bec1bdaaf6d5d173743933e5d77d71ea2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169547
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30681}
When selecting all streams there was an index out of bounds
checking the selected temporal layer, which is -1 so was irrelevant.
My fix is to prevent selecting a temporal layer and all streams
at the same time.
Bug: webrtc:11402
Change-Id: I0641b926cba35878945b866f2c59b4b0281f0852
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169720
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#30679}
This patch introduces 2 new field trials that make p2p_transport_channel
to send ping on network switches. The purpose of this is to reduce the
time that the peers disagre on which connection to use.
- send_ping_on_switch_ice_controlling
Send a ping from the ICE_CONTROLLING side when switching connection.
- send_ping_on_nomination_ice_controlled
Send a ping from the ICE_CONTROLLED side when a connection has been
nominated by remote side.
The extra traffic by these PINGS are considered harmless since
network switches does not happen that often.
Bug: webrtc:10273
Change-Id: Id7abe268c79ceb2404c0543849d5666466e58d0c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169550
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30668}
Note that this wasn't actually making a difference since both do the
same thing effectively.
Bug: webrtc:11386
Change-Id: I49d84d363dce12eabeb3770b40abdfdb674a05ac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169433
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30665}
