This test drives the new tools_webrtc/remove_extra_namespace.py tool.
Bug: None
Change-Id: I9b590aa1213e4cace2d64d555f4dafd893f03606
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327021
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41141}
This is a pure rename+move of PeerConnectionSimulcastMediaFlowTests.
The reason for renaming is to reflect that a) this is an integration
test, not a unit test, and b) not all of the tests use simulcast (some
use a single encoding, i.e. singlecast or SVC).
Shared helper functions between PeerConnectionEncodingsIntegrationTest
and PeerConnectionSimulcastTests are placed in a test-only util file.
# Already pass, no need to wait for chromium bots for webrtc testonly CL
NOTRY=True
Bug: webrtc:15063
Change-Id: Iec90d1a7ab712be1395c7644723422c8c6179974
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300540
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39799}
We've only seen heap-use-after-free issues when the test continues to
run after EXPECT_TRUE_WAIT failures. This may speculatively reduce the
risk of flakes by aborting the test as soon as a failure happens.
Ideally the peer connections would all close due to going out of scope
making frame encoding after this point an impossibility.
Bug: webrtc:15018
Change-Id: I69d8bcf0f76e3bfb591d2ea81b9e9f68b1f11ffe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300481
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39782}
In case this triggers unexpected error handling on ASAN.
Bug: webrtc:15018
Change-Id: Iec8154081f3831ee60902bb94900d79a98ea01fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300480
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39779}
This reverts commit 727014a5f1.
Reason for revert: This didn't seem to help and we should be closing
the PC automatically anyway (in ~PeerConnectionTestWrapper)
Original change's description:
> Close PC before test ends to reduce risk of flake.
>
> From the logs I can't tell if close is happening or not on the bots.
> Let's make it explicit just in case.
>
> Bug: webrtc:15018
> Change-Id: Icfa7fe8587d1516a9ef31e86ade920a6023e619b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300364
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Auto-Submit: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Commit-Queue: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#39768}
Bug: webrtc:15018
Change-Id: I6ee693f382a5d104b2b0088d0c1dae7ae39501d1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300520
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39778}
From the logs I can't tell if close is happening or not on the bots.
Let's make it explicit just in case.
Bug: webrtc:15018
Change-Id: Icfa7fe8587d1516a9ef31e86ade920a6023e619b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300364
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39768}
Only in testing environments are the task queues shut down while sources
still have media flowing. It's still not clear why heap-use-after-free
happens, since it should be enough to close the PC, but it is clear that
the crash is happening due to frames flowing while the test is shutting
down, which is not something happening outside of testing.
In an attempt to deflake, this CL makes sure to manually stop the
test-only sources before closing the peer connection.
Bug: webrtc:15018
Change-Id: I48ee131a8994c9c4caee1bb4875580d255b97da1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299944
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39752}
The EncoderStreamFactory triggers different code paths depending on
`number_of_streams`: one for simulcast and one for non-simulcast.
The non-simulcast path is desired for both normal streams and SVC
streams.
The simulcast path gives sensible max bitrates for 4:2:1 scenarios, but
when encodings like {active,inactive,inactive} is specified in order to
do standard SVC, the max bps of the first encoding is so low that an
SVC stream will never send more than its first spatial layer (even when
scaleResolutionDownBy is 1).
Because of this, standard SVC is broken. This CL fixes this problem by
using the CreateDefaultVideoStreams() code path instead, which is the
same one that legacy SVC uses. With this fix, legacy and standard SVC
produce the same behavior regarding bitrate.
An added benefit of this is that numberOfSimulcastStreams == 1 in the
standard SVC path as well.
{active,inactive,inactive} tests are updated to verify the full
resolution is achieved after ramp-up. I've also confirmed that this
fixes the bug in Canary, see https://crbug.com/1428098#c2.
Bug: chromium:1428098, webrtc:15041, webrtc:15034
Change-Id: Ia1eb4ff59c4e2a56af833f7ac907a66bca8ea054
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299147
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39697}
This reverts commit cac9a55ddf.
Reason for revert: WebRTC importer consistently fails this test.
Original change's description:
> Add legacy SVC test that all layers can be inactivated.
>
> A larger version of this test was previously landed but got reverted
> due to failures only happening on the importer bot (not on the CQ or
> locally).
>
> This is a smaller version of the test that does something we should
> support: being able to inactive all encodings of a VP9 legacy SVC
> stream.
>
> Let's land and see if any issues are reproducible (expecting revert).
>
> Bug: webrtc:15033
> Change-Id: I88da1facf4ef05299f3392b86a0e3df029ebe264
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299006
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39684}
Bug: webrtc:15033
Change-Id: Ia31f125bd6782ed38653c1e5cdcc29a8a0eff874
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299145
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39686}
Update some uses of scalabilityMode to also set scaleResolutionDownBy.
Nothing changes in these tests because they were either single stream
cases, fallback was happening anyway or the test was doing VP8, but by
specifying scaleResolutionDownBy we make these tests consistent and
explicit about wanting to exercise the "standard path".
Partly a style thing and partly not wanting the test to pass for the
wrong reason.
Bug: None
Change-Id: I1d2e688976a4e6c160e90474e2416a18d795d41b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299078
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39685}
A larger version of this test was previously landed but got reverted
due to failures only happening on the importer bot (not on the CQ or
locally).
This is a smaller version of the test that does something we should
support: being able to inactive all encodings of a VP9 legacy SVC
stream.
Let's land and see if any issues are reproducible (expecting revert).
Bug: webrtc:15033
Change-Id: I88da1facf4ef05299f3392b86a0e3df029ebe264
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299006
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39684}
A similar test to this was landed but got reverted due to failing on the
importer bot. That is being investigated here[1]. This CL relands parts
of the original test that we believe are NOT causing issues.
This CL is not expected to fail on the importer, let's land and verify.
[1] https://webrtc-review.googlesource.com/c/src/+/299006
Bug: webrtc:15033
Change-Id: If11e459b17d3606da3ddff0742e5429c642f7e83
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299007
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39666}
The test is flaking during shutdown in general, but this is especially
apparent on ASAN bots that don't retry. It is related to
heap-use-after-free and is believef to be a test-only problem.
Bug: webrtc:15018
Change-Id: I593c18dbbe45605404b17af74fd7101f118db7bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299003
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39661}
This makes "WebRTC-AllowDisablingLegacyScalability" enabled-by-default,
meaning any app can opt-in to spec-compliant simulcast when
scalabilityMode is specified.
The opt-in criteria is also made more restricitve: you now have to
specify both scalabilityMode and scaleResolutionDownBy to get simulcast,
otherwise you continue to get legacy "single stream" path.
The reason for this is not to cause any surprises in use cases like
[{scalabilityMode:"L1T1", active:true}, {active:false}, {active:false}]
In cases like this where scaleResolutionDownBy is not specified, it
defaults to 4:2:1 if simulcast is used but the legacy path caps it to
one stream, meaning full resolution. By restricing simulcast only to
cases that set scaleResolutionDownBy, we remove the risk of an app
getting a different resolution than expected due to opt-in.
Bug: webrtc:14884, webrtc:15005
Change-Id: I5efb87af60afaeb1e3ff76698d887aaa1f9d63a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298922
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39660}
Various "if streams == 1" cases are updated to "if
IsSinglecastOrAllNonFirstLayersInactive()" in order not to cause subtle
differences between VP9 {active} and VP9 {active,inactive,inactive}.
This CL also affects a line that conditionally sets
`simulcastStream[0].active = codec_active` so it seemed fitting to
improve the test coverage of "if all streams are inactive, don't send".
Bug: webrtc:15028
Change-Id: I8872dc8be0f2dfc1d8914bdba5e6433f9ba8cbfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298881
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39656}
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}
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}
This reverts commit 75990b9a8f.
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}
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}
- Patch Set 1: Re-land of 297982.
- Patch Set 2: Skip test (return early) if AV1 is not available.
Original CL description (297982):
This is something we get "for free" with the
"WebRTC-AllowDisablingLegacyScalability" field trial that has been
wired up to support VP9 simulcast.
This test works and passes, however the ramp-up time is pretty bad.
- VP9 simulcast takes approximately 4 seconds to ramp up.
- VP9 SVC takes approximately 16 seconds to ramp up.
- AV1 simulcast takes approximately 22 seconds to ramp up.
A TODO is added (webrtc:15006) and the test is given extra timeout,
a full minute to get bytes flowing on all layers.
Despite ramp-up being bad, it's important to test that AV1 simulcast
is in fact working to avoid regressions due to obsolete assumptions
about which codec do or do not support simulcast. AV1 simulcast is an
opt-in feature so there is no harm in the API not being perfect yet.
Bug: webrtc:15005, webrtc:15006
Change-Id: Ie8ec9f17c709ef93525e4ea5feb7c95496062add
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298050
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39597}
This reverts commit 2d3b294e49.
Reason for revert: The CL was believed to make AV1 always available
but it turned out that the import bots still failed due to not
having AV1, so it is better to use the built in factories than
to make custom test-only ones.
Original change's description:
> Ensure AV1 is always available in PeerConnectionSimulcastTests.
>
> Unblocks a WebRTC import where a bot without AV1 support would
> otherwise have been running and failing during setting codec
> preferences.
>
> # Non-chromium bots passed, no need to wait for chromium to land.
> # Want to unblock importer.
> NOTRY=True
>
> Bug: webrtc:15005
> Change-Id: I93c6a0ce5591a057c3a0ee49f6dbaef3676c0e1d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298021
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#39592}
Bug: webrtc:15005
Change-Id: I8f0850852edb0d0234000b2d956e2648a9adf904
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298120
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39596}
This reverts commit c8ab6c449c.
Reason for revert: new test fails to run upstream
Original change's description:
> Exercise AV1 simulcast paths in tests.
>
> This is something we get "for free" with the
> "WebRTC-AllowDisablingLegacyScalability" field trial that has been
> wired up to support VP9 simulcast.
>
> This test works and passes, however the ramp-up time is pretty bad.
> - VP9 simulcast takes approximately 4 seconds to ramp up.
> - VP9 SVC takes approximately 16 seconds to ramp up.
> - AV1 simulcast takes approximately 22 seconds to ramp up.
>
> A TODO is added (webrtc:15006) and the test is given extra timeout,
> a full minute to get bytes flowing on all layers.
>
> Despite ramp-up being bad, it's important to test that AV1 simulcast
> is in fact working to avoid regressions due to obsolete assumptions
> about which codec do or do not support simulcast. AV1 simulcast is an
> opt-in feature so there is no harm in the API not being perfect yet.
>
> Bug: webrtc:15005, webrtc:15006
> Change-Id: If0158d172647f0462bd6db802406249d93e01871
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297982
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39586}
Bug: webrtc:15005, webrtc:15006
Change-Id: I7da6df8bb51219e7d0acfd3b62b4ec08e25bfdc7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298049
Owners-Override: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#39595}
Unblocks a WebRTC import where a bot without AV1 support would
otherwise have been running and failing during setting codec
preferences.
# Non-chromium bots passed, no need to wait for chromium to land.
# Want to unblock importer.
NOTRY=True
Bug: webrtc:15005
Change-Id: I93c6a0ce5591a057c3a0ee49f6dbaef3676c0e1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298021
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39592}
This is something we get "for free" with the
"WebRTC-AllowDisablingLegacyScalability" field trial that has been
wired up to support VP9 simulcast.
This test works and passes, however the ramp-up time is pretty bad.
- VP9 simulcast takes approximately 4 seconds to ramp up.
- VP9 SVC takes approximately 16 seconds to ramp up.
- AV1 simulcast takes approximately 22 seconds to ramp up.
A TODO is added (webrtc:15006) and the test is given extra timeout,
a full minute to get bytes flowing on all layers.
Despite ramp-up being bad, it's important to test that AV1 simulcast
is in fact working to avoid regressions due to obsolete assumptions
about which codec do or do not support simulcast. AV1 simulcast is an
opt-in feature so there is no harm in the API not being perfect yet.
Bug: webrtc:15005, webrtc:15006
Change-Id: If0158d172647f0462bd6db802406249d93e01871
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297982
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39586}
The goal of the VP9 simulcast project is that when `scalability_mode`
is set, multiple encodings are always interpreted as simulcast, even
if VP9 or AV1 is used. This CL makes this so, but only if the flag
"WebRTC-AllowDisablingLegacyScalability" is "/Enabled/". This allows us
to make "SendingThreeEncodings_VP9_Simulcast" EXPECT VP9 simulcast.
When we are ready to ship we will remove the need to use the field
trial, but before we ship this we'll want to revisit if
SvcRateAllocator can be updated to support simulcast. (Today if we use
SvcRateAllocator when VP9 simulcast is used, all encodings except the
first one get bitrate=0, causing the test to fail because media is not
flowing on all layers.) For now, a TODO is added.
Bug: webrtc:14884
Change-Id: Ie20ae748b0c0405162f3a1b015ab94956ef83dae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297340
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39552}
The test was assuming that after all thee layers have bytesSent > 0 we
would have fully ramped up to the expected resolutions. But there are
reasons why this may not be true, such as if adaptation kicks in.
This CL attempts to de-flake by using kLongTimeoutForRampUp when
checking the resolutions as well.
// Just increasing a timeout...
NOTRY=True
Bug: webrtc:14884
Change-Id: I5ef57ec3e3cc99552c9ae32a6fdf07889ff06ee1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296883
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39534}
to RTCInboundRtpStreamStats and RTCOutboundRtpStreamStats respectively
which follows the camel-casing convention used elsewhere.
The old name is kept around as an alias for a limited amount of time
to allow upgrading dependencies.
BUG=webrtc:14973
Change-Id: Ibf4e65933fd6cc2e7e89955042f6f8fb0f6c7853
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296261
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39497}
Attempting to SVC can fail for two reasons:
1. If codec preferences does not contain a codec that supports SVC,
setParameters() rejects, leaving scalabilityMode undefined.
2. If codec preferences does contain a codec that support SVC,
setParameters() accepts the scalabilityMode, but if a codec is
configured in response to negotiation that does not support SVC,
fallback happens.
In the 1) path, undefined scalabilityMode results in VP8 L1T1.
In the 2) path, SVC fallback results in scalabilityMode being set to
L1T2, resulting in VP8 L1T2.
Whether we fail late or early resulting in different configurations may
not be obvious so its good to test these.
Bug: webrtc:14884
Change-Id: Ic5502b90c1628310a7a78ade2ad9fa0d81d91502
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295872
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39474}
This test does not change any parameters.
Bug: webrtc:14884
Change-Id: Ic315c1b10e729f1f179570350028eef604d714b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296041
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39473}
Due to recent confusion about when to use L1T1, L1T2 or L1T3 and
different paths triggering different configurations for these, let's
make the simulcast tests more explicit about which scalability mode we
are getting for each setup.
Bug: webrtc:14884
Change-Id: I6ac20768a1fa9db08fdef032d07b4794a3e66d81
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295873
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39465}
The test only exists #if defined(WEBRTC_USE_H264) because H264 is not
available in all testing environments (e.g. Android bots fail without
these guards).
Bug: webrtc:14884
Change-Id: Ic1ff6b16f49f6666df042304ee98d826778da122
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295508
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39424}
The helper function is updated to decide whether or not to log; in the
VP8 simulcast test we're expected to have ramped up already and want
the logging but in the VP9 test ramp up time is significant and we
don't want to log spam.
The kLongTimeoutForRampingUp time is increased from 20s to 30s because
we noticed that SVC is slower to ramp up than simulcast and we don't
want flaky bots. The value 30s is still 2-3 times longer than what was
needed locally, but we want the bots to have plenty of margins so we
update it "just in case" even if 20s may have been enough.
Bug: webrtc:14884
Change-Id: I4b3cea20b65b2601982edcaaa90af2ef949a23ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295507
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39423}
Looked in to this some more and had a chat with Evan, and L1T3 being
reported in getStats() is a real sign that L1T3 is used. This CL updates
the comments of the VP9 simulcast test to reflect that this is what
we are getting, not SVC, even if layers are being dropped etc.
Bug: webrtc:14884
Change-Id: I15eac981625302480ce337879138537c0ad73664
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295540
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39421}
Resolution expectations:
- Expect that the resolution for each RID matches what is configured.
Parameters fix:
- Due to a bug in the VP9 Simulcast test, we were accidentally modifying
a copy of the encodings and SetParameters() was a NO-OP. This is now
fixed, which sadly revealed that the SVC fallback that is happening
is not reflected in `scalability_mode`.
Bug: webrtc:14884
Change-Id: I5127e7b874c59816fcf58ff354de8d77b74d4b3e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295501
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39416}
Call operators do not improve code clarity, and usage was moderate.
Bug: None
Change-Id: I8d86bd7d435ce88e99f4abee8ab95a336d47dc22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292960
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39294}
Today the default 3 encodings path for VP9 is to trigger legacy SVC,
which is tested by "SendingThreeEncodings_VP9_LegacySVC".
This CL adds another test that does not rely on the default
`scalability_mode` and instead explicitly asks for simulcast (3 x L1T3).
When VP9 simulcast is supported (https://crbug.com/webrtc/14884), this
API pattern will allow the app to ask for standard behavior while the
default path still exists for backwards-compatibility.
Because we don't support VP9 simulcast yet, this test still triggers
legacy fallback which is wrong so this test mostly serves to document
current behavior, but see Patch Set 1 for side-by-side comparison of
what we want to EXPECT and what we currently EXPECT.
In the meantime, this CL helps exercise code paths that are possible
to trigger as of M111. The TODOs will be addressed as part of
https://crbug.com/webrtc/14884.
Bug: webrtc:14884
Change-Id: Id901eea8f399223afd5a1731a3323e5134686134
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292720
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39281}
When asking for 3 encodings of VP9, which the spec says is simulcast,
you don't get simulcast but instead you get one RTP stream sending SVC.
This results in a single "outbound-rtp" but GetParameters() still says
3 encodings are used. We know we get SVC because the scalabilityMode
from getStats() says "L3T3_KEY".
In a future CL we will add simulcast VP9 support when
`scalability_mode` is specified in the API but we'll need to continue
to support the legacy SVC code paths until that has been deprecated
and removed (https://crbug.com/webrtc/14889).
Bug: webrtc:14884
Change-Id: Ibeca44b7a0b93097ad9525e45ebbca3b7663c686
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292581
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39278}
Explicitly configure VP8 and verify the codec and scalability mode makes
sense. In preparation for doing the same with VP9 when VP9 simulcast is
supported.
Bug: webrtc:14885, webrtc:14884
Change-Id: If0c89e9b5de4fc63a59e17412fe4f0317fd61229
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292580
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39272}
Previous tests only asserted that O/A succeeded and that the number of
encodings was as expected. This test goes further and also asserts that
bytesSent eventually becomes non-zero (after an initial ramp-up time).
Let's get testing straight before we add VP9 simulcast support.
Bug: webrtc:14885, webrtc:14884
Change-Id: Idccce66698a077264fa0df2c448c8474d2439aea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291960
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39271}
RID is defined for multiple usages in RFC 8851, but we only support
usage with a=simulcast as specified in RFC 8853.
Bug: chromium:1341043
Change-Id: Ie72074c5b394bdc41865938a86ec9c7629e1f5e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267628
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37417}
