Fix multiple use-after-move issues in VideoReceiveStream2, as found by
clang-tidy:
video/video_receive_stream2.cc:259:
'config' used after it was moved
video/video_receive_stream2.cc:199:
move occurred here
Bug: chromium:1122844
Change-Id: I6367dc835f002718a5353c3e0b64c2a154e79925
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/241201
Auto-Submit: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35530}
Addresses case where 540*960 would not get a 135*240 layer.
Bug: webrtc:13469
Change-Id: Icc291c65114fb400cc71659d76a786e359e5996c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239820
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Konrad Hofbauer <hofbauer@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35507}
This class is superseded by VideoReceiveStream2.
Bug: webrtc:11489
Change-Id: I02b844868bafe67ce3e924fc23029ec300e934a7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/240063
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@google.com>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35491}
This was a remenant leftover from a previous design, which was no longer
valid after the switch to TaskQueues. ReturnReason::kStopped was not
used at all, and so Timeout or FrameFound can be inferred from whether
the frame is null or not.
Bug: webrtc:13343, webrtc:13346
Change-Id: Ib0f847b1e1192e32ea11208e48f5a3892703521e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239651
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35490}
When a frame is assembled `packet_infos` is moved and must be
re-initialized before potentially being used in another iteration of the
loop. Clear `packet_infos` immediately instead of relying on it being
implicitly cleared in the next iteration of the loop.
Bug: None
Change-Id: I954aaa0c6df296cc2a27b3ab496e49fac200f135
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238981
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35441}
This test being flaky impeded the landing of
https://webrtc-review.googlesource.com/c/src/+/239126. Fix by
ensuring the test's OnSendRtp guts don't execute past all streams
stopped.
Bug: None
Change-Id: Ie8aefb3bb03c09d2a9514acecd162e7c079c77c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239363
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35432}
The encoders wrapped in VideoStreamEncoder grossly over-estimates
available bitrate when capture FPS falls close to zero, and frames
re-commence highly frequent delivery. Avoid this by moving the input
RateStatistics inside VSE into the frame cadence adapter, and changing
the reported framerate under zero-hertz encoding mode to always return
the configured max FPS.
Bug: chromium:1255737
Change-Id: Iaa71ef51c0755b12e24e435d86d9562122ed494e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239126
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35431}
This change moves the responsibility of posting
EncoderSwitchRequestCallback calls closer to the top-level
users which has a better idea about threading requirements.
The change is planned to be followed-up with more changes removing
the need for VSE to post to the worker thread.
Bug: webrtc:13414, chromium:1255737
Change-Id: I57a2962a70e9f245460c59c0d61824371394b952
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238420
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35387}
This change switches the sequence used by the FrameCadenceAdapter
to be the encoder_queue, enabling VideoStreamEncoder::OnFrame to be
invoked directly on the encoder_queue and eliminates the contained
PostTasks.
Bug: chromium:1255737
Change-Id: Ib86fc96ad2be9a38585fef2535855e3f9cc7e57c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238171
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35380}
Add implementation of RTC_DCHECK_NOTREACHED equal to the RTC_NOTREACHED.
The new macros will replace the old one when old one's usage will be
removed. The idea of the renaming to provide a clear signal that this
is debug build only macros and will be stripped in the production build.
Bug: webrtc:9065
Change-Id: I4c35d8b03e74a4b3fd1ae75dba2f9c05643101db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237802
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35348}
This CL set the spatial id in LibaomAv1Encoder and set correct number
of spatial layers for AV1 in FrameEncodeMetadataWriter.
Bug: None
Change-Id: I40092e45be88ec9ab75f228d9ca84c44e3cad326
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237662
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Zhaoliang Ma <zhaoliang.ma@intel.com>
Cr-Commit-Position: refs/heads/main@{#35339}
VideoStreamEncoder receives frames on an undefined threading
context with the only requirement being that frames are serially
arriving. This CL changes this to post all frames arriving at the
FrameCadenceAdapter to the worker thread before further
processing, transitively leading to frame entry into the
VideoStreamEncoder on the worker thread.
Bug: chromium:1255737
Change-Id: I04d69cb4a5048d671d2dcd3bd6d669fbcda52b3f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237142
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35320}
https://chromium-swarm.appspot.com/task?id=56dfaf30fa11e510
Due to recent changes, this test sometimes crashes because of
use after free.
Fix this by adding a PendingTaskSafetyFlag to not access `stream_`
after it has been deleted.
Bug: webrtc:13315, webrtc:13351
Change-Id: I7cb180bcab1d79b39737c53704c5fe8a2ca28b7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236660
Commit-Queue: Byoungchan Lee <daniel.l@hpcnt.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35319}
The test has a ModuleRtpRtcpImpl2 which is destroyed long
after test transports are removed, leading to a UAF.
Fix by overriding OnStreamsStopped which is called before
transports are removed.
TESTED=Asan now passes 1000/1000, failed 4/1000 before.
Fixed: chromium:1235251, b:192567426
Change-Id: Ie9135685e81712e38c4b00355debfc67c1f603bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237345
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35318}
This change introduces a new FrameCadenceAdapter class which takes the
role of being a VideoFrameSinkInterface<> instead of VideoStreamEncoder.
The FrameCadenceAdapter will see its functionality grow in future CLs
and eventually enable screenshare capture sources to have zero hertz as
the minimum capture frequency.
This CL moves logic related to UMA collection and constraints into the
adapter.
The adapter has two major modes. Future functionality is planned to be
added under the WebRTC-ZeroHertzScreenshare field trial. Unit tests are
added that verify passthrough operation when WebRTC-ZeroHertzScreenshare
isn't specified or disabled.
Just specifying the WebRTC-ZeroHertzScreenshare field trial isn't
enough to activate the feature, but the caller has to additionally
configure screen content type, minimum FPS 0, and maximum FPS > 0 for
the new mode.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I1799110ed40843152786ad80df10acfb83a608b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236682
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35315}
The sequences of threads entering the VideoStreamEncoder has been
unclear. Fix this by renaming the uninformational |main_queue_| to
|worker_queue_|, and introduce a new |network_queue_| which is set
on construction.
Bug: chromium:1255737
Change-Id: Ic4d3a5b8188b8cc98e60b72aee2c09c9afbc7356
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236523
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35283}
The synchronously waiting SendTask() helper method should never be
called from within OnSendRtp() as that risks a deadlock with the
shutdown of the test.
This CL reverts an earlier disabling which did not correctly identify
the root cause.
Bug: webrtc:13291
Change-Id: Ia3c3417e0cbfb7011bb2439a52f976b946adad78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235721
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35244}
This change adds a few UMAs to inform on the usage of frame
rate constraints related to screenshare sessions.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: Icdd011a8e7df837416d603beeb0866d9eb1918e7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235368
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35238}
This change
- adds new type VideoTrackSourceConstraints expressing min/max FPS
constraints.
- adds new method VideoTrackSourceInterface::ProcessConstraints.
- adds new method VideoSinkInterface<>::OnConstraintsChanged.
- updates AdaptedVideoTrackSource and VideoBroadcaster to forward
the constraints to sinks.
- adds several unit tests for the added functionality.
- and finally, implements OnConstraintsChanged in VideoStreamEncoder.
Chromium will be updated in coming CLs to supply constraints set
through the MediaStream module.
go/rtc-0hz-present
Bug: chromium:1255737
No-Try: true
Change-Id: Iffef239217269c332a1aaa902ddeae2440929e22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235040
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35197}
Encoder info will be modified at runtime. In fact, we should reduce the
number of 'full' ReconfigureEncoder(). If only need subset of it at
runtime, consider handle it in VideoStreamEncoder::EncodeVideoFrame().
Consider two cases:
Re-configure scalers when encoder info changed. Consider two cases:
1. When the status of the scaler changes from enabled to disabled, if we
don't do this CL, scaler will adapt up/down to trigger an unnecessary
full ReconfigureEncoder() when the scaler should be banned.
2. When the status of the scaler changes from disabled to enabled, if we
don't do this CL, scaler will not work until some code trigger
ReconfigureEncoder(). In extreme cases, the scaler doesn't even work for
a long time when we expect that the scaler should work.
This CL aims to make scalers work properly when encoder info changed.
BUG: None
Change-Id: Iec17730b5fac5e642c0fb2d9b11c5b7434f0a220
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233384
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35175}
Use config from FakeEncoder in some tests.
Bug: none
Change-Id: I1d7e01f604f8aabb5d6815bb519ef2532d024d76
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233243
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35138}
First CL to try to understand the extent of the cleanup needed in
order to remove -Wno-shadow and follow Chromium on enabling this
diagnostic.
Bug: webrtc:13219
Change-Id: Ie699762da50fe3dbc08b1fd92220962d4b7da86b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233641
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35134}
The |slice_qp_detla| reported by the hardware is not credible, which
causing the quality scaler cannot work properly,the resolution cannot
be adjusted correctly.
To fix this issue, this CL implements a bandwidth scaler which is used
for adjust resolution, this scaler will be used when QP based quality
scaler is not working due to untrusted QP reported by HW AVC encoder.
Bug: webrtc:12942
Change-Id: I2fc5f07a5400ec7e5ead2c2c502faee84d7f2a76
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228860
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35120}
min_pacing:8ms, to avoid the situation where bursts of frames are sent
to the decoder at once due to network jitter. The bursts of frames
caused the queues further down in the processing to be full and
therefore drop all frames.
max_decode_queue_size:8, in the event that too many frames have piled
up, do as before and send all frames to the decoder to avoid building
up any latency.
These setting only affect the low-latency video pipeline that is enabled
by setting the playout RTP header extension to min=0ms, max>0ms.
Bug: chromium:1138888
Change-Id: I8154bf3efe7450b770da8387f8fb6b23f6be26bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233220
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35119}
Currently the implementation of FrameTransformers uses distinct,
incompatible types for recevied vs about-to-be-sent frames. This adds a
flag in the interface so we can at least check that we are being given
the correct type. crbug.com/1250638 tracks removing the need for this.
Chrome will be updated after this to check the direction flag and provide
a javascript error if the wrong type of frame is written into the
encoded insertable streams writable stream, rather than crashing.
Bug: chromium:1247260
Change-Id: I9cbb66962ea0718ed47c5e5dba19a8ff9635b0b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232301
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <toprice@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35100}
maxBitrate is set to a minimum of kEncoderMinBitrateKbps in VideoCodecInitializer::SetupCodec and cannot be zero at this point.
Bug: none
Change-Id: I4e062b054d99fabc1a9650260db03dd45b033c3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230142
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35094}
Call SetMaxBitrate when encoder is configured instead of in OnMaybeEncodeFrame (which is called after the initial frame dropping ->
max bitrate is not set for dropped frames).
Added support for single active stream configuration.
Bug: none
Change-Id: I33ff96e7feed70b9ea3c9b3da89f117859108347
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231681
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34973}
The experiment WebRTC-PreStreamDecoders (aka Lazy decoder creation) has
investigated the benefit of only creating a subset of all decoders
during negotiation and the remaining decoders on demand.
This CL changes the default value to only create one decoder during
negotiation. This frees up hardware resources and reduces the SDP
negotiation time.
Bug: chromium:1202042
Change-Id: I6e2206839162aa857fcc948ccd53d0ff91cbdeaf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231643
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34959}
Setting the rtp header extensions on the packet delivery thread
(currently worker, soon to be network), is now possible without
taking the hit of deleting and recreating the receive stream (and
rtp receiver and related state).
Bug: webrtc:11993
Change-Id: I9bbe306844a25d85d79cd216092ead66eaf68960
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223741
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34953}
