This sincludes the SimulcastEncoderAdapter and the
VideoEncoderSoftwareFallbackWrapper. This avoids converting
the frame when that is not needed.
Bug: webrtc:11976
Change-Id: I686725ecfb79c3b8d87d587a907da1602483bfe8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187343
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#32389}
VideoBitrateAllocation is instead reported through the EncoderSink.
Enable VideoBitrateAllocation reporting from WebRtcVideoChannel::AddSendStream in preparation for
using the extension RtpVideoLayersAllocationExtension instead of RTCP XR.
Bug: webrtc:12000
Change-Id: I5ea8e4f237a1c4e84a89cbfd97ac4353d4c2984f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186940
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32347}
This reverts commit f5e261aaf65cdf2eb903cdf40d651846be44f447.
Reason for revert: Breaks downstream projects.
Original change's description:
> Introduce RTC_NO_UNIQUE_ADDRESS.
>
> This macro introduces the possibility to suggest the compiler that a
> data member doesn't need an address different from other non static
> data members.
>
> The usage of a macro is to maintain portability since at the moment
> the attribute [[no_unique_address]] is only supported by clang
> with at least -std=c++11 but it should be supported by all the
> compilers starting from C++20.
>
> Bug: webrtc:11495
> Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32246}
TBR=mbonadei@webrtc.org,kwiberg@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:11495
Change-Id: Ice318d1b11ca3dff09c190187a0b0a32ca945fe3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186944
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32335}
Currently, when only max bitrate available and min bitratea & target
bitrate are missing from encoding config, the target bitrate is decided
by the calculation from GetSimulcastConfig() according to width/height/qp.
The max bitrate doesn't play a role here other than ensure target < max.
This will make the target bitrate cap at some calculated number even
when control message gives much larger allocation through max bitrate.
In our cases, the L0 (at 180p) is capped at 80-90kbps even control
message gives L0's max bitrate over 300kbps. This under-use of bandwidth
happens to all layer other than top layer. Top layer will be compensated
with all the left bandwidth up to max at last.
Since in web api, we cannot pass down either min bitrate or target bitrate
(https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpEncodingParameters).
We propose a new logic to take max bitrate into consideration in this case,
use 3/4 max bitrate or calculated target bitrate whichever is larger.
Bug: None
Change-Id: I2234b4636daa379fd47d4bbe764cf8307b9a1ea4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186161
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32308}
API to injecting a heavy audio processing operation into WebRTC audio capture pipeline
Bug: webrtc:12003
Change-Id: I9f6f58f468bd84efd0a9d53d703db6229a03959e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165788
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Olga Sharonova <olka@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32291}
This macro introduces the possibility to suggest the compiler that a
data member doesn't need an address different from other non static
data members.
The usage of a macro is to maintain portability since at the moment
the attribute [[no_unique_address]] is only supported by clang
with at least -std=c++11 but it should be supported by all the
compilers starting from C++20.
Bug: webrtc:11495
Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32246}
The former was unused, the latter is replaced with the explicit C++11
deletions. The related RTC_DISALLOW_COPY_AND_ASSIGN is left for now,
it is used in a lot more places.
Bug: None
Change-Id: I49503e7f2b9ff43c6285f8695833479bbc18c380
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/185500
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32224}
This is a reland of
https://webrtc-review.googlesource.com/c/src/+/174261
Patchset 1 contains the old cl (plus a merge conflict fix).
Later patchets are bufixes: A PeerConnection can be created without a
Call instance (in the case of DataChannel only), so we can't always
use that to fetch the current trials.
Old CL descritpion:
This replaces field_trial:: -based functions from system_wrappers.
Field trials are still used as fallback, but injectable trials are now
possible.
// Since re-land is otherwise unchanged, setting previous reviewers as TBR
TBR=kthelgason@webrtc.org,mbonadei@webrtc.org,stefan@webrtc.org,srte@webrtc.org
Bug: webrtc:11926
Change-Id: I57a9e8c3454f226f77fb93215bcac83da65034b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/185003
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32163}
RequestEncoderFallback, RequestEncoderSwitch and
SetVideoCodecSwitchingEnabledRequest are now all called on the
worker thread. Before, the work already happened on that thread but
WebRtcVideoChannel adapted internally when needed.
With this CL, there are thread checks to make sure that these calls are
always made the same way, we don't need the async invoker and there
are fewer calls out from the encoder thread in VideoStreamEncoder
(reducing the chance of unintentional blocking).
Bug: webrtc:11908
Change-Id: If8738bc2a708a0fefc6fe850b32655f049f30bdc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184603
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32151}
This turned out to be a bit complicated, mostly
related to the tests, but here's what's changed:
* No AsyncInvoker (and avoid ClearInternal) in
WebRtcVideoSendStream (WVSS)
* The reason it was there is due to a "design leak" from
VideoSourceSinkController/VideoStreamEncoder where the former uses
locks in all methods and is unaware of a threading model. That design
affected downstream objects, pushed the need for an async hop into
WVSS and added a lock.
A suggestion was made to address this in a follow-up change, here:
https://webrtc-review.googlesource.com/c/src/+/165684
* All methods in VideoSourceSinkController are now called on a known
and checked sequence and this CL removes the lock. This also makes
checking state consistent (i.e. calling a getter twice in a row on the
same sequence, will always return the same value, avoiding race with
other threads).
* Handling of reporting state changes from the encoder queue to the
VSSC, is done by VideoStreamEncoder.
* VideoSendStreamImpl is still instantiated on the incorrect thread [1]
but has two initialization steps [2]. The second one already runs on
the right thread. Addressing that TODO [1] is something we should do
but it has side effects to consider. For the purposes of this CL
the steps relating to the encoder (setting the sink pointer) have
been moved to [2].
[1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;l=94
[2] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;drc=f4a9991cce74a37d006438ec0e366313ed33162e;l=115
Bug: webrtc:11222, webrtc:11908
Change-Id: Ie46d46e3a52bbe225951b4bd580ecb8cc9cad873
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184508
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32150}
Add a get_and_clear_legacy_stats flag to AudioReceiveStream::GetStats,
to distinguish calls from standard GetStats and legacy GetStats.
Add const method NetEq::CurrentNetworkStatistics to get current
values of stateless NetEq stats. Standard GetStats will then call this
method instead of NetEq::NetworkStatistics.
Bug: webrtc:11622
Change-Id: I3833a246a9e39b18c99657a738da22c6e2bd5f5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/183600
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32092}
This fixes some edge cases where early media could cause default
stream that block the actual signaled media from beind delivered.
Bug: webrtc:11477
Change-Id: I8b26df63a690861bd19f083102d1395e882f8733
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/183120
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32030}
Deletes all webrtc usage of this member. Next step is to delete
any downstream references, and when that's done, the member can be
deleted.
Bug: None
Change-Id: I3f3a94a063dccf56468a1069653efd3809875b01
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/181201
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31911}
this makes the association between opus and red a bit more obvious.
Also it allows access to the opus payload type which might be
used in the fmtp line in a future CL
BUG=webrtc:11640
Change-Id: I04e0648aedf049d103e3c3481c8712dfc9b79538
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178800
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31868}
This is a reland of 32ca95145c4636374266f5b5d4d1ac43658bc758
Fix includes not enabling the screenshare conference behavior on non
screenshare sources even if the flag is enabled.
Original change's description:
> Only enable conference mode simulcast allocations with flag enabled
>
> Non-conference mode simulcast screenshares were mistakenly using the
> conference mode semantics in the simulcast rate allocator, which broke
> spec compliant usage in some situation.
>
> This behavior should only be used when explicitly using the SDP entry
> "a=x-google-flag:conference" in both offer and answer.
>
> Bug: webrtc:11310, chromium:1093819
> Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31828}
Bug: webrtc:11310
Bug: chromium:1093819
Change-Id: Ic933f93a5c4bad20583354fe821f8a1170e911cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180802
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31847}
This member of the CodecInfo struct was set in several places, but not
used for anything. To aid deletion, this cl defines a default implementation
of VideoEncoderFactory::QueryVideoEncoder.
The next step is to delete almost all downstream implementations of that method,
since the only classes that have to implement it are the few factories that
produce "internal source" encoders, e.g., for Chromium remoting.
Bug: None
Change-Id: I1f0dbf0d302933004ebdc779460cb2cb3a894e02
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179520
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31844}
only enables RFC 2198 redundancy if it has a higher preference
than Opus. This means it not used by default but can be
chosen with setCodecPreferences.
BUG=webrtc:11640
Change-Id: I84ff2ca518da70440297a667dedba5cf4484eed7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178742
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31830}
This reverts commit 32ca95145c4636374266f5b5d4d1ac43658bc758.
Reason for revert: Internal test failure
Original change's description:
> Only enable conference mode simulcast allocations with flag enabled
>
> Non-conference mode simulcast screenshares were mistakenly using the
> conference mode semantics in the simulcast rate allocator, which broke
> spec compliant usage in some situation.
>
> This behavior should only be used when explicitly using the SDP entry
> "a=x-google-flag:conference" in both offer and answer.
>
> Bug: webrtc:11310, chromium:1093819
> Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31828}
TBR=ilnik@webrtc.org,hta@webrtc.org,orphis@webrtc.org
Change-Id: I5ccb6e87594f491ba09fe6b837ee24d63db878ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11310
Bug: chromium:1093819
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180801
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31829}
Non-conference mode simulcast screenshares were mistakenly using the
conference mode semantics in the simulcast rate allocator, which broke
spec compliant usage in some situation.
This behavior should only be used when explicitly using the SDP entry
"a=x-google-flag:conference" in both offer and answer.
Bug: webrtc:11310, chromium:1093819
Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31828}
This CL changes the style of logging for an API which is essential when
WebRTC is used in Chrome. By changing the format, we can more easily
tie in (search for tags etc.) logs from WebRTC with logs in Chrome.
See e.g.
https://chromium-review.googlesource.com/c/chromium/src/+/2093443
for more details.
I decided to use a new private method to avoid using rtc::StringBuilder.
The idea was to make the log statements less complex and more condensed.
Tbr: mbonadei
Bug: webrtc:11493
Change-Id: I46b4a933ad62ac1db376743b4a41b62c5f8c6ac6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172841
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31808}
When enabled:
- Creates an audio network adapter config that is passed to audio send
stream.
- Configures a lower default min bitrate.
All parameters can be configured via a field trial that can also force
enable the audio network adaptor (this is mainly intended for testing).
Bug: chromium:1086942
Change-Id: I48dfcca1ee2948084199352abed6212a6c78eb6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177840
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31565}
negotiates the RED codec for opus audio behind a field trial
WebRTC-Audio-Redundancy
This adds the following line to the SDP:
a=rtpmap:someid RED/48000/2
To test start Chrome with
--force-fieldtrials=WebRTC-Audio-Red-For-Opus/Enabled
BUG=webrtc:11640
Change-Id: I8fa9fb07d03db5f90cdb08765baaa03d3d0458cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176372
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31562}
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}
This fixes a crash that could happen if substreams exist but there is
no kMedia substream yet. There was an assumption that we either had no
substreams or at least one kMedia substream, but this was not true.
The correct thing to do is to ignore substream stats that are not
associated with any kMedia substream, because we only produce
"outbound-rtp" stats objects for existing kMedia substreams.
A test is added to make sure no stats are returned. Prior to the fix,
this test would crash.
Bug: chromium:1090712
Change-Id: Ib1f8494a162542ae56bdd2df7618775a3473419b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176446
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31442}
