- 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 2d3b294e49027607c80766c50f1c3c8d7d4b38b9.
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 c8ab6c449c84f17fabf8da58456d396bdb5da762.
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}
Originally DMABufs were imported into a temporary buffer followed by a
copy operation into the desktop frame itself. This is not needed as we
can import them directly into desktop frames and avoid this overhead.
Also drop support for MemPtr buffers as both Mutter and KWin don't seem
to support them and they are going to be too slow anyway.
Testing with latest Chromium, I could see two processes with usage around 20% and 40% without this change going down to 10% and 20% with
this change applied.
Bug: webrtc:13429
Bug: chrome:1378258
Change-Id: Ice3292528ff56300931c8638f8e03d4883d5e331
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297501
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#39594}
When allocating bitrate, some parts of the coded directly uses the bitrate parameter, while others lets it be capped by VideoCodec.maxBitrate. This may result in an inconsistency between expected and actual number of temporal layers, causing a crash.
Even better would be to update VideoCodecInitializer to not create
VideoCodec instances where there's not enough maxBitrate to activate
all spatial layers - but that's a much more complex issue.
Bug: chromium:1423365
Change-Id: Ic74b68261ea6043f1795accdd9864319ab535435
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298041
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39593}
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 enables testing HW H265 codecs on devices where the support is available.
Bug: b/261160916, webrtc:14852
Change-Id: I32d102fcf483ea4ba46d6f5161342dbb584e7cc9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298040
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39591}
It seems like this is legacy and not useful. A comment mentions
transitioning between CNG and DTMF modes, but there is no way this can
happen currently.
Bug: webrtc:13322
Change-Id: I9e4706cb6ee145ee37a9e11e7cab6ea4ff697dc4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297980
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39590}
Previously cloned frames ended up with the metadata saying it was a
delta frame, even for keyframes.
Bug: chromium:1425362
Change-Id: I7a9438f124b75f6be9a5705d20fa65b2f7179a22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298020
Commit-Queue: Tony Herre <herre@google.com>
Auto-Submit: Tony Herre <herre@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39588}
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}
Following https://webrtc-review.googlesource.com/c/src/+/297100
it seems that sctp_data_channels_ gets modified while we're iterating
through it. This temporary fix creates a copy of the array and iterates
through the copy instead of sctp_data_channels_. A follow-up CL (or CLs)
will provide more clarity, testing and regression guards.
Bug: webrtc:15004
Change-Id: I0cb5dfb6829d36b51328875c8c9cfa392ff393a7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297981
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39584}
This is in preparation of merging the PLC and CNG decision logic.
Bug: webrtc:13322
Change-Id: Ica782440b0d5c43c92ad5c33631b0cb708b51b0e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297861
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39580}
Because the adapter has a passthrough mode, it can already handle both
singlecast and simulcast cases, meaning the proxy is no longer providing
value. Let's delete.
Bug: webrtc:15001
Change-Id: I480eaba599448e9b82b8cf7f829dc35ad6ce0434
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297740
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39579}
Since AddTrack now has an implicit init_encodings value, it will also
have a StableState saved when associating a transceiver.
That state may not have a saved mid and mline_index, and so on a
rollback, it could blindly reset the mid and mline_index of an
associated transceiver.
This is wrong, the mid and mline_index of associated transceivers
should only be updated when the StableState objects actually
have one saved.
Bug: chromium:1424238
Change-Id: I8e80a04cd072d90200ca7643de892c0ef29b1f1a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297920
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39577}
All tests do this already except for RTCStatsCollectorTest.
Bug: none
Change-Id: I318f45a2c79b3d07ca6c92902ebb4f0622ec3200
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297862
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39576}
libaom uses the quantizer as an index for an array of size 64, so
encoder_settings_.qpMax must be <= 63.
Add a comment to LibaomAv1Encoder::SetSvcParams() to explain why the
method doesn't initialize svc_params.layer_target_bitrate.
Bug: None
Change-Id: I26be80de005752214365abbe8b9b32dc976cee0b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293680
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Cr-Commit-Position: refs/heads/main@{#39572}
The log_prefix frequently used in dcSCTP is intended to be used
to separate logs from different sockets within the same log output,
typically in unit tests. Every log entry always has the file and
line, so it's not important to add more information to the log prefix
that indicates _where_ it's logged. So those have been removed.
Also, since log_prefix is a string (typically 32 bytes) and it's
never changing during the lifetime of the socket, pass and store it
as a absl::string_view to save memory.
Bug: None
Change-Id: I10466710ca6c2badfcd3adc5630426a90ca74204
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274704
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39571}
This removes the behavior of not requesting datachannel if the first
datachannel is closed before the offer is created.
Bug: chromium:1423562
Change-Id: I90eab0f908507e65d9ee3dff51842ee6d61a8aa9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297860
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39570}
`CopyPixelsFrom` uses libyuv underneath and has handrolled
implementation for copying with AVX.
Bug: chromium:1424776
Change-Id: I4fafeba97fcc1d2200a10070837672175a1dfc50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297800
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39567}
Fuchsia's libc provides `select` and `poll` but not `epoll`.
This CL adds a `WaitPoll` method, which is modeled after `WaitSelect` but uses `poll`. The pre-existing `WaitPoll` method was renamed to `WaitPollOneDispatcher`.
TESTED="2p video call on Fuchsia. WaitPoll is faster compared to
WaitSelect, primarily because WaitSelect pessimistically calls
getsockopt(SO_ERROR) on each fd, while WaitPoll does so only on fds that
have entered an error state."
Original author: tombergan@google.com
Bug: None
Change-Id: I83cc824fca40d691fd93712c1c933ff21b3f877c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296826
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39564}
This struct only contains two member variables now and there isn't
much value added by having it.
Low-Coverage-Reason: No change in coverage, CL modifies uncovered RTC_LOG lines.
Bug: none
Change-Id: I924d450f4c8f8e49b1cfeabaebee9fd5235a90cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297360
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39563}
This includes:
* SignalDataChannelTransportWritable_s
* SignalDataChannelTransportReceivedData_s
* SignalDataChannelTransportChannelClosing_s
* Removing sigslot::has_slots<> inheritance from SctpDataChannel
Instead, we use the existing sctp_data_channels_ vector of channels
known to the DCC to deliver the callbacks.
Bug: webrtc:11943, webrtc:11547
Change-Id: I7935d7505856eedf04981b8ba665ef8419166c1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297100
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39557}
Add a WebRTC-specific arg that can be used to control use of targets
that rely on //third_party/google_benchmarks, so the .gni in that
directory can eventually be removed.
Bug: chromium:1404759
Change-Id: I2a9422fae119ca13eb50028d962fc0a671b5fb33
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297460
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39553}
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}
This removes one sigslot and also simplifies the teardown procedure
of a data channel when the channel is closed by the transport.
In this case we no longer need an additional async teardown task that
releases the last remaining reference to the channel.
Bug: webrtc:11943, webrtc:11547
Change-Id: I1c170349a6cbb3cb3c5a47d284e3a3d416c92b11
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296981
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39551}
