A recent bugfix[1] introduced having to reconfigure the encoder in
response to restrictions updating for the sake of not getting stuck at
the wrong resolution in some cases.
But the newly added ReconfigureEncoder() calls happened too early/often,
and the initial frame dropper got confused thinking resolution changes
were not in response to adaptation (restrictions) when they in fact were.
The CL wrongly disabled the "reset initial frame dropper" logic, when
the correct solution to this problem should have been to delay the
ReconfigurationEncoder() call to the next frame (using
`pending_encoder_reconfiguration_ = true`).
With this delay the initial frame dropper is not confused and we can
restore the old "reset" logic, fixing the regression.
[1] https://webrtc-review.googlesource.com/c/src/+/360200
Bug: b/364252657
Change-Id: I6b93f4cc44eb12b1bbbda0d8d1e9906c29b615a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361740
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42961}
This makes it simpler to use in more contexts.
Bug: b/364184684
Change-Id: I1b08ebd24e51ba1b3f85261eed503a78cd006fd8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361480
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42956}
The fieldtrials can be used to override the static QP threshold
that is used in QualityConvergenceMonitor to determine if an
encoded video stream has reached its target quality.
The fieldtrials do not change the dynamic detection.
Bug: chromium:328598314
Change-Id: I5995860eff461f0c712293e34cf75834ce414bed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361201
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42928}
This is to make it clear that this field indicate whether the upper bits
of the sequence number should be communicated. However, the current
implementation only sets the field if it is a key frame.
Bug: webrtc:358039777
Change-Id: Ic2c8b6d91499e4e5cf25b8ce9591d326d7044fb0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361402
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42924}
To make it available for constructing ModuleRtpRtcpImpl2
Bug: webrtc:362762208
Change-Id: Ic6ad339170c6aedb6c0bf42419964741d4d32bcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360921
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42888}
Normally (scaleResolutionDownBy) restrictions are applied at the source
which changes the input frame size which triggers reconfiguration with
appropriate scaling factors.
But when requested_resolution is used, encoder settings are by
definition not relative to the input frame size. In order for
restrictions to have an effect, they are applied inside
ReconfigureEncoder(): you get the minimum between the requested
resolution and the restricted resolution.
ReconfigureEncoder() happens when you SetParameters(), but the bug
here is that we don't do it again once the restrictions are updated.
So if restrictions are 540p when you ask for 720p, you get 540p and
after restrictions change to unlimited you're still stuck in 540p.
The fix is to also trigger ReconfigureEncoder() inside
OnVideoSourceRestrictionsUpdated() when the restricted resolution is
changing and a requested_resolution is configured.
To ensure reconfiguring the encoder "on the fly" like this does not
reset initial frame dropping logic, InitialFrameDropper caring about
input frame size changing is made conditional on not using
requested_resolution.
# Slow purple bots failing but they are not affected by this change.
NOTRY=True
Bug: webrtc:361477261
Change-Id: I1389aa16cf408b0d14e0b5b6f68c2442db955be9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360200
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42882}
It looks like the map `content_specific_stats_` is just carried over into `aggregated_stats` without doing any important processing. This seems to be redundant and hence, removing it in this CL.
Bug: None
Change-Id: Ia4a5de03999ecd33d387014928cba322bb11ee93
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360745
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42870}
The original CL overlooked the possibility that the encoder may be
reconfigured in the middle of a stream.
Restructure the code so that all calls to QP convergence controller
happen on the encoder queue.
A side effect of this CL is that `EncodedImage::SetAtTargetQuality()`
is never called. The information is supplied to the frame cadence
adapter directly without this intermediate step.
`EncodedImage::SetAtTargetQuality()` and
`EncodedImage::IsAtTargetQuality()` are being marked as deprecated
in https://webrtc-review.googlesource.com/c/src/+/359660.
Bug: chromium:359410061
Change-Id: I941b5f60b1a9fd7694dbedf2f3e4ff5253ccf357
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359640
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42788}
The functions will be used to map a frame's QP to its optimal standard
deviation for the Gaussian kernel for the filter applied in the
automatic corruption detection algorithm.
Bug: b/358039777
Change-Id: Idb3b8cfdbd4a405151c660df87205e3949f9b085
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359380
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42777}
e.g all files in the api/test folder not including subdirectories
Bug: webrtc:42226242
Change-Id: I18d74a18f8feec41eb252faa9acfffd1d6f45ce4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359420
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Dor Hen <dorhen@meta.com>
Cr-Commit-Position: refs/heads/main@{#42773}
This CL fixes a problem where VSEAM's `queue_` was dereferenced
post destruction. A sequence triggering it is:
0. FrameCadenceAdapter (FCA) is configured with Metronome with >= 34 ms tick delay.
1. A frame is queued for processing on worker queue.
2. The FCA is destroyed. The contained VSyncEncodeAdapterMode instance is scheduled for deletion on worker queue.
3. Encode queue is destroyed.
4. Worker queue is executed, which runs a task that dereferences `queue_`.
Bug: chromium:356423094
Change-Id: Iae8dc070304ef5ec0cfb0b4f27bbb7fe86e7def7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358660
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42745}
This CL only adds variables necessary for the feature, which will be
implemented in later CLs.
Bug: webrtc:350555527
Change-Id: I71e56666e629f56168d316bf693150c0df0e2ecf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356740
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Dan Tan <dwtan@google.com>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42698}
This requires making CallConfig move-only so it can hold a unique_ptr to
the factory, but as discussed with Danil, that seems fine.
Bug: chromium:355610792
Change-Id: Ie52e33faaa4a2af748daeb25f5327b7a532936e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357862
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42679}
Currently this class assumed that if the same RTP sequence number is unwrapped again result would be the same.
That might not be true when several packets were inserted in between these two calls and unwrapper changed its state
This CL propose instead to unwrap once, and save the result in the intermediate struct.
To minimize the change and the risk, only redundant unwrapping is replaced to use unwrapped sequence number
Bug: webrtc:353565743
Change-Id: I8a18c8c206a0e16010951cabcf81dd9cb1588eda
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357660
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42662}
This is a reland of commit 09f03be54804e81f626c26e8fde8c86cc952545f
Use max_num_layers instead of encoder_config.number_of_streams when calculation stream resolutions in EncoderStreamFactory::GetStreamResolutions().
Original change's description:
> Pass true stream resolutions to GetSimulcastConfig()
>
> Before this change GetSimulcastConfig() received only maximum resolution as an input parameter and derived resolutions for low quality simulcast streams assuming 1/2 scaling factor [1]. These days applications can configure resolution scaling factors via RtpEncodingParameters. If the configured resolution scaling factors were different from 1/2 then we got wrong bitrate limits from GetSimulcastConfig(). Now resolutions are calculated using scaling factor from RtpEncodingParameters (or default 1/2) for all streams in EncoderStreamFactory::CreateEncoderStreams() and then passed to GetSimulcastConfig().
>
> Moved tests from simulcast_unittest.cc to encoder_stream_factory_unittest.cc. Mapping of old to new tests:
> * GetConfigWithLimitedMaxLayersForResolution -> ReducesStreamCountWhenResolutionIsLow
> * GetConfigWithLowResolutionScreenshare -> ReducesLegacyScreencastStreamCountWhenResolutionIsLow
> * GetConfigWithNotLimitedMaxLayersForResolution -> KeepsStreamCountUnchangedWhenLegacyLimitIsDisabled
> * GetConfigWithNormalizedResolution -> AdjustsResolutionWhenUnaligned
> * GetConfigWithNormalizedResolutionDivisibleBy4 -> MakesResolutionDivisibleBy4
> * GetConfigWithNormalizedResolutionDivisibleBy8 -> not needed (MakesResolutionDivisibleBy4 should be enough).
> * GetConfigForLegacyLayerLimit -> KeepsStreamCountUnchangedWhenResolutionIsHigh and ReducesStreamCountWhenResolutionIsLow
> * GetConfigForLegacyLayerLimitWithRequiredHD -> KeepsStreamCountUnchangedWhenLegacyLimitIsDisabled
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/video/config/simulcast.cc;l=297-298;drc=1b78a7eb3f418460da03672b1d1af1d9488bb544
>
> Bug: webrtc:351644568, b/352504711
> Change-Id: I0028904ab0bb1e27b9c1b7cd3fb9a8ccf447fa35
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357280
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#42651}
Bug: webrtc:351644568, b/352504711
Change-Id: Ib3fd859257b61c2a5d695b8b8f45c95495117c0e
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357520
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42654}
This reverts commit 09f03be54804e81f626c26e8fde8c86cc952545f.
Reason for revert: breaks downstream projects
Original change's description:
> Pass true stream resolutions to GetSimulcastConfig()
>
> Before this change GetSimulcastConfig() received only maximum resolution as an input parameter and derived resolutions for low quality simulcast streams assuming 1/2 scaling factor [1]. These days applications can configure resolution scaling factors via RtpEncodingParameters. If the configured resolution scaling factors were different from 1/2 then we got wrong bitrate limits from GetSimulcastConfig(). Now resolutions are calculated using scaling factor from RtpEncodingParameters (or default 1/2) for all streams in EncoderStreamFactory::CreateEncoderStreams() and then passed to GetSimulcastConfig().
>
> Moved tests from simulcast_unittest.cc to encoder_stream_factory_unittest.cc. Mapping of old to new tests:
> * GetConfigWithLimitedMaxLayersForResolution -> ReducesStreamCountWhenResolutionIsLow
> * GetConfigWithLowResolutionScreenshare -> ReducesLegacyScreencastStreamCountWhenResolutionIsLow
> * GetConfigWithNotLimitedMaxLayersForResolution -> KeepsStreamCountUnchangedWhenLegacyLimitIsDisabled
> * GetConfigWithNormalizedResolution -> AdjustsResolutionWhenUnaligned
> * GetConfigWithNormalizedResolutionDivisibleBy4 -> MakesResolutionDivisibleBy4
> * GetConfigWithNormalizedResolutionDivisibleBy8 -> not needed (MakesResolutionDivisibleBy4 should be enough).
> * GetConfigForLegacyLayerLimit -> KeepsStreamCountUnchangedWhenResolutionIsHigh and ReducesStreamCountWhenResolutionIsLow
> * GetConfigForLegacyLayerLimitWithRequiredHD -> KeepsStreamCountUnchangedWhenLegacyLimitIsDisabled
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/video/config/simulcast.cc;l=297-298;drc=1b78a7eb3f418460da03672b1d1af1d9488bb544
>
> Bug: webrtc:351644568, b/352504711
> Change-Id: I0028904ab0bb1e27b9c1b7cd3fb9a8ccf447fa35
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357280
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#42651}
Bug: webrtc:351644568, b/352504711
Change-Id: I7aadbe49419b7ac610db4db99284fdcdce9deff5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357500
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42653}
Before this change GetSimulcastConfig() received only maximum resolution as an input parameter and derived resolutions for low quality simulcast streams assuming 1/2 scaling factor [1]. These days applications can configure resolution scaling factors via RtpEncodingParameters. If the configured resolution scaling factors were different from 1/2 then we got wrong bitrate limits from GetSimulcastConfig(). Now resolutions are calculated using scaling factor from RtpEncodingParameters (or default 1/2) for all streams in EncoderStreamFactory::CreateEncoderStreams() and then passed to GetSimulcastConfig().
Moved tests from simulcast_unittest.cc to encoder_stream_factory_unittest.cc. Mapping of old to new tests:
* GetConfigWithLimitedMaxLayersForResolution -> ReducesStreamCountWhenResolutionIsLow
* GetConfigWithLowResolutionScreenshare -> ReducesLegacyScreencastStreamCountWhenResolutionIsLow
* GetConfigWithNotLimitedMaxLayersForResolution -> KeepsStreamCountUnchangedWhenLegacyLimitIsDisabled
* GetConfigWithNormalizedResolution -> AdjustsResolutionWhenUnaligned
* GetConfigWithNormalizedResolutionDivisibleBy4 -> MakesResolutionDivisibleBy4
* GetConfigWithNormalizedResolutionDivisibleBy8 -> not needed (MakesResolutionDivisibleBy4 should be enough).
* GetConfigForLegacyLayerLimit -> KeepsStreamCountUnchangedWhenResolutionIsHigh and ReducesStreamCountWhenResolutionIsLow
* GetConfigForLegacyLayerLimitWithRequiredHD -> KeepsStreamCountUnchangedWhenLegacyLimitIsDisabled
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/video/config/simulcast.cc;l=297-298;drc=1b78a7eb3f418460da03672b1d1af1d9488bb544
Bug: webrtc:351644568, b/352504711
Change-Id: I0028904ab0bb1e27b9c1b7cd3fb9a8ccf447fa35
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357280
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42651}
QualityConvergenceController is a layer between VideoStreamEncoder
and QualityConvergenceMonitor that takes care of the simulcast
logic.
Bug: chromium:328598314
Change-Id: Iad8a9d9138e69a60fd508a7ef038220947888f0a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356420
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42642}
This is a cleanup of simulcast.cc. Remove GetNormalSimulcastLayers and GetScreenshareLayers from simulcast.h. Move the implementations to anonymous namespace in simulcast.cc.
Bug: webrtc:351644568, b/352504711
Change-Id: Iff03161e5c44cb0e7faa60b16cfc2fc9b903d5ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357103
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42635}
This is a cleanup of simulcast.cc. max_qp is not needed to decide simulcast config. Move setting of max QP in VideoStream one level up, to EncoderStreamFactory::CreateEncoderStreams(), where it can be set per stream.
Bug: webrtc:351644568, b/352504711
Change-Id: Ia0e3e9d90032383574dc8867b30d362e9c5df7e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357102
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42634}
This is a cleanup of simulcast.cc. bitrate_priority is not needed to decide simulcast config. Move setting of bitrate priority in VideoStream one level up, to EncoderStreamFactory::CreateEncoderStreams().
Bug: webrtc:351644568
Change-Id: I002d728ccf8d141fe4bbb32b390129ce57c830cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357101
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42629}
Call it once instead of 3 times.
Also remove FindSimulcastMaxBitrate, FindSimulcastTargetBitrate, FindSimulcastMinBitrate and a one parameter less version of InterpolateSimulcastFormat.
Bug: b/337757868, webrtc:351644568
Change-Id: I7b4002fc3134c47f368bb833925c959a07ce5177
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356980
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42623}
The function has been deprecated in favor of
FrameEncodeMetadataWriter::FillMetadataAndTimingInfo().
Bug: chromium:328598314
Change-Id: Iaf2008e855dbd71f2d7cf412d95c5932b3645d71
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356042
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42613}
* Simplified ctor. Get settings (max_qp, content_type, etc) from encoder_config passed to CreateEncoderStreams().
* Some tests assigned VideoEncoderConfig::video_stream_factory to EncoderStreamFactory they created. That's not really needed. VideoStreamEncoder creates the factory if video_stream_factory is not provided [1]. Removed video_stream_factory initialization in tests.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/video/video_stream_encoder.cc;l=1002;drc=1d7d0e6e2c5002815853be251ce43fe88779ac85
Bug: b/347150850, webrtc:42233936
Change-Id: Ie0322abb6c48e1a9bd10e9ed3879e3ed484fea5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355321
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42608}
Only minor positive changes seen in initial testing. Let's default-
enable and monitor behavior through the normal release cycle.
Bug: b/349561566
Change-Id: Id6b39daa159068bf076acc34888b5d7eaf110329
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356641
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42607}
in addition to last received frame rtp timestamp. This helps in cases
where frames continue to be received but the decoder fails to decode.
BUG=None
Change-Id: I56ad5f9ef85cc598d3c1a1971c4c697eb6b70165
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356080
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Markus Handell <handellm@google.com>
Cr-Commit-Position: refs/heads/main@{#42596}
Behind a flag, the new behavior changes how the "media rate" utilization
is calculated:
* Instead of per spatial & temporal layer, it's per spatial layer only.
* Overshoot is compared to real target vs adjusted target.
* Window takes quite periods/frame drops more into consideration.
This should lead to less push-back when not network constrained and
complex content is used causing bursty behavior.
Bug: b/349561566
Change-Id: I402e6531183493c963fec48ae363ce0b859b396a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356480
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42593}
This class measures the allocated cumulative byte budget (as specified
by one or more rate updates) and the actual cumulative number of bytes
produced over a sliding window.
A utilization factor (produced bytes / budgeted bytes) is calculated
seen from the first data point timestamp until the last data point
timestamp plus the amount time needed to send that last data point
given no further updates to the rate.
Wireup to EncoderBitrateAdjuster will happen in a follow-up CL.
Bug: b/349561566
Change-Id: Id0dc183b07a96366531007be9ff1c1ec6574e9ff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356200
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42591}
Bitrate limits should have been applied to the spatial layers in ApplySpatialLayerBitrateLimits (and usage is restricted to a single active stream/layer).
Bug: b/299588022
Change-Id: Iaae4ece28b8a95eea7d4bacba292847ba5b4000b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355841
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42588}
Some dependencies still exist but are a bit more complex to remove.
This CL removes either unused or easily replaced with ToString()
instances of ostream usage. In one case, moving the operator<<
implementation to the one test file that requires it.
Bug: webrtc:8982
Change-Id: Ia5c840b12a42893494af401317a3daf2fe50ba9b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/356240
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42582}
The temporal id must be read from `EncodedImage` rather than codec
specifics for AV1. Furthermore, in some configs the spatial id of
`EncodedImage` is populated and set to 0 while the simulcast id can
also be simultaneously populated and set to values, including non-zero.
To solve this, just take the max of the two.
Bug: b/349561566
Change-Id: I46c61b7f0fff7a7ab8d7262c3a8d413f49b3286a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355904
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42573}
Add default values and a static Create() function that determines
the parameters to use based on the specified codec and potential
field trial overrides.
Bug: chromium:328598314
Change-Id: I7a9331a1fd0ed4bd258788760592ea84e535e43b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355903
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Markus Handell <handellm@google.com>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42567}
