This cl/ adds resource adapation to the requested_resolution
feature. The restrictions that are sent to the video source
are also saved inside video_stream_encoder and used when
determining layer resolution.
Anticipated further patches
4) Let VideoSource do adaption if possible
Bug: webrtc:14451
Change-Id: Ia9b990a6b92b76af7ff6665a562f84585f79c35b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277580
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38306}
This cl/ implements configuring of encode resolution
in the video_stream_encoder (webrtc_video_engine) in
a way that is independent of frame resolution (i.e
not using scale_resolution_down_by).
The cl/ reuses the VideoAdapter as is, and hence
the output resolution will be the same as it is today.
Anticipated further patches
3) Hook up resource adaptation
4) Let VideoSource do adaption if possible
Bug: webrtc:14451
Change-Id: I881b031c5b23be26cacfe138730154f1cb1b66a8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276742
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38245}
This cl/ changes so that the EncoderStreamFactory is
not created inside WebRtcVideoSendStream (webrtc_video_engine).
The benifit of this is that the VideoStreamEncoder can then
amend the EncoderStreamFactory with state (and types)
w/o exposing it in VideoEncoderConfig.
I.e as an alternative to changes done inside
https://webrtc-review.googlesource.com/c/src/+/276742.
The fake_webrtc_call is modified to (if needed) create
it's own EncoderStreamFactory if needed.
Note: this cl/ will have to be merged with with
https://webrtc-review.googlesource.com/c/src/+/277002.
Bug: webrtc:14451
Change-Id: I3d896b227d39725ba6409622e8d09d14bd45d5fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277160
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38237}
The Chromium RTCVideoEncoder unfortunately doesn't set if the
result is at target quality, and the definition of the threshold
is buried in libvpx_vp8_encoder.h.
This change
* Updates VideoStreamEncoder to postprocess an incoming EncodedImage
by interpreting the incoming QP information instead.
* Updates the related VideoStreamEncoder test to simulate an encoder
producing images around the QP threshold.
* Updates the steady state VP8 screencast QP threshold to a central
include file.
* Moves this and previously existing EncodedImage post-processing to a
new method AugmentEncodedImage.
Bug: b/245029833
Change-Id: I69ae29ffe501e84f28908f7d9a8cfd066ba82b43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275380
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38091}
BlockingCall doesn't take rtc::Location parameter and thus most of the dependencies on location can be removed
Bug: webrtc:11318
Change-Id: I91a17e342dd9a9e3e2c8f7fbe267474c98a8d0e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274620
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38045}
If a "normal" software buffer frame is dropped during paused state, we
store it as a pending frame and try encoding it after the pause state is
lifted. However, native frames are dropped entirely since keeping e.g.
texture handles for long time periods can lead to side effects.
Work around this by requesting a refresh frame after unpausing if the
dropped frame flag is set.
Bug: webrtc:14276
Change-Id: I9edd1e99454e082bcfe29f3d9041026dd8a390d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270220
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37660}
rtc::TaskQueue is a simple wrapper over TaskQueueBase and adds no
extra features when task queue is used without passing ownership.
Reducing usage of the internal rtc::TaskQueue wrapper gives users more flexibility how TaskQueueBase* is stored.
Bug: webrtc:14169
Change-Id: If5c8827544c843502c7dfcef775ac558de79ec3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/268189
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37549}
This cl/ adds a way of setting an EncoderSelector on a specific
RtpSenderInterface. This makes it possible to easily use different
EncoderSelector on different streams within the same or different PeerConnections.
The cl/ is almost identical to the impl. of RtpSenderInterface::SetFrameEncryptor.
Iff a EncoderSelector is set on the RtpSender, it will take precedence
over the VideoEncoderFactory::GetEncoderSelector.
Bug: webrtc:14122
Change-Id: Ief4f7c06df7f1ef4ce3245de304a48e9de0ad587
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264542
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37150}
In case the encoder TQ has been stopped and doesn't accept more tasks,
we could end up in a hung state during Stop(). This is a hypothetical
situation, but can be simulated in a test and avoided.
Bug: webrtc:14063
Change-Id: I20f48b11b6266f6875ed5e69de3529212505e439
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258125
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36964}
This CL sets speed 9 for all resolutions when two or less cores are
available, as a heuristic for a "slow" machine.
This gives a large speed bost at a relatively small quality loss.
A field-trial kill-switch is available to override this behavior.
Bug: webrtc:13888
Change-Id: I24278a45de000ad7984d0525c47d9eb6b9ab6b60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257421
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36466}
convert almost all of video/ (and the collateral)
Bug: webrtc:10335
Change-Id: Ic94e05937f54d11ee8a635b6b66fd146962d9f11
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/254601
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36192}
Some of the state that's managed in VideoStreamEncoder, is updated
and accessed on the encoder queue, but a method that's used for testing
only (GetAdaptationResources()), represents a race between PostTask
operations that update state and checking for said state on the worker
thread.
This CL removes Wait() operations related to adaptation resources from
the common path and puts one in the test path instead.
Bug: webrtc:13612
Change-Id: Ie3e018e815e24951bc0634ed70de17eaf336a508
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249220
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35797}
Currently if encoder initialization fails WebRTC doesn't send any video.
This CL adds functionality that changes encoder type in such case and
restores the video. If encoder selector is available we switch to
encoder it recommends. Otherwise, VP8 is used as the default fallback
encoder.
Bug: webrtc:13572
Change-Id: Ifcdf707a575711f5ff81f9451caf30140c9171dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246960
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35761}
The frame cadence adapter ignores key frame processing that happens
before the point where zero-hertz mode is activated, which leads to
no refresh frame requests if the key frame request comes too early.
Fix this to register a pending refresh frame request that gets
serviced when zero-hertz mode is activated. The CL changes the
FrameCadenceAdapterInterface::ProcessKeyFrameRequest from returning
whether to request a refresh frame into the frame cadence adapter
actively doing so itself via a new Callback::RequestRefreshFrame
API.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I53c2dbf6468e883eb2a2e81498e7134b1b35c336
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242963
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35598}
Careful analysis of logs related to the requesting of refresh
frames from the source revealed an uncomfortable truth:
zero-hertz mode activates first when the first frame has been
received in the VideoStreamEncoder, because the number of simulcast
layers can only be computed when frame dimensions are known. This
fact means that the currently implemented logic for requesting
refresh frames is noneffective.
Fix this by
1. Activating zero-hertz mode prior of knowing the final layer
count. This causes refresh frame requests to happen without any
frames received from the source.
2. Making layer count dynamically configurable. Zero-hertz mode
considers layer quality unconverged after such a reconfiguration.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I0ecea4d2a8442a00e3b79b146dd39a5f4ac561d9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242860
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35593}
Under zero-hertz mode, provided that a frame arrived to the
VideoStreamEncoder, the receiver may experience up to a second
between incoming frames. This results in key frame requests getting
serviced with that delay, which is undesired.
What's worse is also the fact that if no frame ever arrived to the
VideoStreamEncoder, it will not service the keyframe requests at all
until the first frame comes.
This change introduces VideoSourceInterface::RequestRefreshFrame
which results in a refresh frame being sent from complying sources.
The method is used under zero-hertz mode from the VideoStreamEncoder
when frames didn't arrive to it yet (with changes to the zero-hertz
adapter).
With this change, when the frame adapter has received at least one
frame, it will conditionally repeat the last frame in response to the
key frame request.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I6f97813b3a938747357d45e5dda54f759129b44d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242361
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35562}
The frame cadence adapter previously resulted in unconditional
frame repeating at max FPS. Change this to slow down to an idle
rate (1 Hz) when quality convergence in all configured spatial
layers has been achieved.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: Ifa593dbf8a61aa29da20ac250da332734ae82791
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/241421
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35547}
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}
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}
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}
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}
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}
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}
