Attempting to ship "WebRTC-AllowDisablingLegacyScalability" revealed a
DCHECK that happens when negotiating 3 VP9 streams prior to the
setParameters() call:
1. By default, `scalability_mode` is missing, so those 3 streams
defaulted to legacy SVC, meaning only a single stream is used.
2. Then, setParameters() was called to make
`encodings[0].scalability_mode = "L2T2_KEY"` and
`encodings[1-2].active = false`. The inactive streams were just
dummies and never expected to exist.
Without simulcast support this is OK, because both 1) and 2) are
interpreted to have a single stream. But with simulcast support, 1) is
interpreted as single stream and 2) as three streams (1 active, 2
inactive). This should be roughly the same setup, but our code treats
them differently.
The DCHECK crash was a mismatch in number of streams in one of the
layers.
The fix is to re-create the streams when the number of streams change
for this reason. The new test revealed other issues and fixes too:
- Support for multiple spatial layers (e.g. "L2T2_KEY") when multiple
encodings exist but only one encoding is active.
- Allow inactive layers not to have a scalability mode set.
A laundry list (https://crbug.com/webrtc/15028) has been created to
update known places doing "if streams == 1" that need to do "if
active streams == 1" instead.
Credit:
The RecreateWebRtcStream() fix is based on eshr@'s POC from
https://webrtc-review.googlesource.com/c/src/+/298565.
Bug: webrtc:15016
Change-Id: I909a3f83a4ef53562894549ade0a870b208cec7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298443
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#39651}
Drop support for old compositors that don't use DmaBufs the way they are
supposed to be used now. There is now a whole negotiation process that
includes DmaBuf modifiers and there is also support for renegotiation in
case we fail to import DmaBufs with certain modifier. This is something
that didn't exist before and in such case, failing to import DmaBufs we
would just end up with broken screen sharing. For that reason it would
be better to use MemFD instead to make sure old compositors will work
just fine
Bug: webrtc:15029
Change-Id: Icc303504e510adc829c12feff7178ae01578a6da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298700
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#39649}
This is to allow external tests to depend on it.
Bug: none
Change-Id: Ic8e2f864041d959f673e7f2c18eb563a13274dcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298745
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39646}
Logs if the mouse cursor has moved and if so if it is embedded in the
captured DXGI frame or not.
Bug: chromium:1421656
Change-Id: Ic8fa8a5a3c020ec28b04064c765b1c204accec1c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298564
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39644}
This allows the SslRole to be queried from the network thread which
will simplify some code paths and avoid thread hopping.
The next steps will be to remove GetSctpSslRole and only query the
DTLS role on the network thread and start combining other operations.
Bug: webrtc:11547
Change-Id: I222dc838fc5ee274a294c8d81d38b5a4ea8fea1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298302
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39642}
If during shutdown the pacer has packets enqueued during pause these
packets will be posted to the pacer after the worker thread is free -
after the ssrcs should have been cleared. This fixes flakes in
picutre_id_tests.
Bug: webrtc:14985
Change-Id: Ib5547a501670fc145543df32fdc43bbc6596375f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297401
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39640}
Values of these parameters are always the same and thus can be hardcoded
Bug: None
Change-Id: Ie19a1c6305d503ad2c92af503006a72b7981e178
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298622
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39637}
after the limitation to 32 TURN servers shipped in M110
BUG=webrtc:13195
Change-Id: I247e5b164188751d94eb9f4fb93aadf1dd645d2a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298308
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39634}
Original implementation uses TaskQueue to async execute both `LogToMemory` and `WriteToOutput`. `LogToMemory` is invoked in high frequency, but the execution takes a very short time. It would be a bit more expensive to post on TaskQueue than execution on current thread with locking. It is because that the TaskQueue switches the thread context for execution.
This CL separates `LogToMemory` from TaskQueue to current thread, in
order to avoid frequent context switching; And periodically schedule
`WriteToOutput` to TaskQueue, not block current thread.
Link: https://webrtc-review.googlesource.com/c/src/+/283641
Bug: chromium:1288710
Change-Id: Ic78216aff16d1883b109e360a0892da3ca8f5ecb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295640
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Markus Handell <handellm@google.com>
Cr-Commit-Position: refs/heads/main@{#39629}
This is a small tweak to explicitly remove this second construction
step from SctpDataChannel (async call to OnTransportReady) and move
it over to DataChannelController, which is where OnTransportReady()
is called from otherwise.
Bug: webrtc:11547
Change-Id: Ie86fa85cbb79b405248f88b47d5920c7f163dba6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297921
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39627}
Based on previous discussions I would have thought that this test would
fail, but it turns out that it passes. See referenced bug for context.
Bug: webrtc:15021
Change-Id: I845b48f688fb25942e3b770d50cafbf8a0bafe94
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298562
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39625}
This cl per default enable the experiment WebRTC-SCM-Timestamp but
leaves the wiring in place for now to explictly allow disabling it.
Bug: webrtc:5773, webrtc:14066
Change-Id: I6118eef73384791ab4d1377e35d36435dc4fa0e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298442
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39624}
so the size and order corresponds to the local capabilities.
The direction may differ.
BUG=chromium:1051821
Change-Id: Icf5312237b8ed137f822c9f7dd35f70a01d2df99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298043
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39623}
They are called only by ReceivedSideCongestionController that already
ensures all access is synchronized.
Bug: None
Change-Id: I0f87e24e3fbb0bd8f6ff679fb949d2373c554fba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269300
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39622}
Also make it possible to pause an already paused stream by making it a no-op.
Change-Id: Id10f74a4c6464067ae63208162194f020c6470eb
Bug: b/271542055
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298202
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39620}
This avoids a couple of layers of error code conversion, reduces
dependency on cricket error types and allows us to preserve error
information from dcsctp. Along the way remove SendDataResult.
Bug: none
Change-Id: I1ad18a8f0b2fb181745b19c49f36f270708720c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298305
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39619}
The motivation for this is to not have to implement this pattern:
foo.h:
class Foo {
public:
Foo();
private:
SequenceChecker checker_;
};
foo.cc:
Foo::Foo() {
checker_.Detach();
}
And instead be able to do this inline in the .h file:
class Foo {
public:
Foo();
private:
SequenceChecker checker_{SequenceChecker::kDetached};
};
Bug: none
Change-Id: Idd7ca82d15c2f77f3aaccf26f1943a49f4b40661
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298445
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39616}
Prior to this CL we would EXPECT_TRUE_WAIT until
HasOutboundRtpExpectedResolutions() confirmed that we achieved the
maximum expected resolution on all simulcast layers. This was meant to
catch bugs in case the wrong layers were configured with the wrong
layer resolutions.
The problem is that if CPU or BW adaptation kicks in, all layers get
downscaled by some factor and the test may not always recover in time,
e.g. if running on slow slow bots.
This CL relaxes the expectation only to fail if the resolution
exceeds what we expect, not if they are smaller. This is not as air
tight but it should still catch most bugs of interest and reduce
flakiness.
This was reported in comment https://crbug.com/webrtc/15018#c14 but
note that this CL does not attempt to fix the other ASAN issue.
Bug: webrtc:15018
Change-Id: I3305bdade5d1626b09aa5c67217bdedb22cdd876
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298563
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/main@{#39615}
Initialization of Android HW codecs takes hundreds milliseconds. Exclude this time from frame processing time of first frame by initializing codecs before starting encoding/decoding.
Bug: b/261160916, webrtc:14852
Change-Id: I9ec84c6b12c1d9821b59965cf521170224066563
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298304
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39613}
Rename fuzzer to match name of the object under test
Test is through more modern api
Rewrite fuzzing to better match real input traffic
Bug: webrtc:14859
Change-Id: I217658b64dd2211b06540155f201a9af3d04dedb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297400
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39606}
This reverts commit 75990b9a8f98ea2d597a31472fb778ec4d55f698.
Reason for revert: Breaks downstream, a use case of having three VP9
encodings, scalability mode only specified on the first layer
(L2T2_KEY) and the other two layers not having a scalability mode but
also being active=false appears to trigger a DCHECK in
call/rtp_video_sender.cc:501. More investigation needed
Original change's description:
> Ship ability to opt-in to VP9/AV1 simulcast.
>
> With this unflagging, an app can opt-in to simulcast when using multiple
> encodings by specifying RTCRtpEncodingParameters.scalabilityMode. This
> ensures backwards-compat with apps relying on 3 encodings to mean SVC
> who traditionally have not specified scalabilityMode.
>
> It fixes the spec/API bug of asking for simulcast and not getting
> simulcast. The field trial exists only as a kill-switch with a TODO to
> remove it.
>
> This ships initial support, however note that the VP9/AV1 simulcast uses
> SimulcastRateAllocator (just like VP8/H264 simulcast). This rate
> allocator uses more kbps than SvcRateAllocator. This should be revisited
> to avoid significant higher bitrates, for example when comparing VP9
> simulcast to VP9 SVC.
>
> Shipping the ability for apps to opt-in makes it easier to exercise
> these new code paths and allows initial feedback from developers, but
> due to the high bitrate (= same bitrate as VP8/H264 simulcast today)
> many apps may find that VP9 SVC is still more beneficial for BW reasons.
>
> Bug: webrtc:14884, webrtc:15005
> Change-Id: I748aae1adb47acc8a6b79b5852cff6aa47a46f5d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298046
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Evan Shrubsole <eshr@google.com>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39601}
Bug: webrtc:14884, webrtc:15005
Change-Id: Ic8f77e6a2971f493d6cd8c23faecd435058a8847
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298440
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39605}
These log statements may have been useful when the initial code was
being written but now it's essentially dead code except for when
debugging while working on the code (and then, enabling the log
statements is simple).
Low-Coverage-Reason: CL modifies VERBOSE log lines that aren't currently covered.
Bug: none
Change-Id: Id9a45fe53574d39ff3feba08c596e0ac4ce294fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297760
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39604}
