This reverts commit 1ad3e14e9981772554a848c5034c7c555680aef7.
Reason for revert: Breaks downstream project. We are investigating into a potential problem when running on mobile platforms. We will get back with info or reland.
Original change's description:
> Follow codec preference order for sending codec fallback.
>
> When encoder selector is not enabled, currently we always fallback to
> VP8 no matter how the codec preference is setup. Update to follow codec
> preference order for the fallback.
>
> Bug: chromium:378566918
> Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43566}
Bug: chromium:378566918
Change-Id: I09086b5ad100a8f66e87df167e903d0b5fe5b589
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/372080
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43600}
When encoder selector is not enabled, currently we always fallback to
VP8 no matter how the codec preference is setup. Update to follow codec
preference order for the fallback.
Bug: chromium:378566918
Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43566}
Without this, Firefox wasn't passing WPT
webrtc/simulcast/setParameters-maxFramerate.https.html.
The main issue is the SetRates API's RateControlParameters doesn't have
a way to model maxFramerate for simulcast layers.
A long term fix would probably be to represent maxFramerate for all
simulcast layers in RateControlParameters. This change is a short term
fix, and resets the encoder iff a simulcast layer's maxFramerate has
changed, and also differs from the maxFramerate of the codec (passed to
SetRates), which matches the layer with the highest maxFramerate.
Bug: None
Change-Id: I088dda0fe88092fe5a5cc61114e10847f072a87b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370124
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43497}
`VideoStreamEncoder` should not recreate the
`FrameInstrumentationGenerator` instace unless the encoder is actually
released. Otherwise it will restart and expect a keyframe the encoder
will likely not produce for a while.
Bug: webrtc:358039777
Change-Id: I111149d5e9b632df9eeb88bbbe8a07969c3e3f1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/369740
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43468}
In particular, some platforms have a limited pool of frames in the
capturer stack, so we need to avoid stashing raw frames in the frame
instrumentation generator that may be dropped by limiting the size of
the queue and avoid putting anything in there until we know we will
send it to the encoder.
Bug: webrtc:358039777
Change-Id: I054ae53dd5e6ac6a22da39c5049f47788561e77a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368641
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43432}
Cleanup some of the TODOs for H.265. They are either invalid or their handling should be merged with other codec types.
Bug: chromium:41480904
Change-Id: I76263354b1b87035e240d77283b21a9a26dcb45b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366044
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43359}
After landing this change, we can change the corresponding usage in
blink to start using presentation_timestamp as well and then delete
the remaining usage of capture_time_identifier.
Bug: webrtc:373365537
Change-Id: I0c4f2b6b3822df42d6e3387df2c243c3684d8a41
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365640
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Cr-Commit-Position: refs/heads/main@{#43317}
This is a reland of commit 82617ac51e7825db53451818f4d1ad52b69761fd
The reason for the revert was a downstream use of
`rtc::VideoSinkWants::requested_resolution`, so in this reland we don't
rename this field, it's fine just to rename the one in
RtpEncodingParameters for now.
Original change's description:
> Rename `requested_resolution` to `scale_resolution_down_to`.
>
> This is a pure refactor/rename CL without any changes in behavior.
>
> This field is called scaleResolutionDownTo in the spec and JavaScript.
> Let's make C++ match to avoid confusion.
>
> In order not to break downstream during the transition a variable with
> the old name being a pure reference to the renamed attribute is added.
> This means we have to add custom constructors, but we can change this
> back to "= default" when the transition is completed, which should only
> be a couple of CLs away.
>
> Bug: webrtc:375048799
> Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43300}
NOTRY=True
Bug: webrtc:375048799
Change-Id: Ic4ee156c1d50aa36070a8d84059870791dcbbe5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366660
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43304}
This reverts commit 82617ac51e7825db53451818f4d1ad52b69761fd.
Reason for revert: Break downstream projects
Original change's description:
> Rename `requested_resolution` to `scale_resolution_down_to`.
>
> This is a pure refactor/rename CL without any changes in behavior.
>
> This field is called scaleResolutionDownTo in the spec and JavaScript.
> Let's make C++ match to avoid confusion.
>
> In order not to break downstream during the transition a variable with
> the old name being a pure reference to the renamed attribute is added.
> This means we have to add custom constructors, but we can change this
> back to "= default" when the transition is completed, which should only
> be a couple of CLs away.
>
> Bug: webrtc:375048799
> Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43300}
Bug: webrtc:375048799
Change-Id: Ie41723a39420e12e7b5b681d3d00ccd14f66b4b1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366642
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#43301}
This is a pure refactor/rename CL without any changes in behavior.
This field is called scaleResolutionDownTo in the spec and JavaScript.
Let's make C++ match to avoid confusion.
In order not to break downstream during the transition a variable with
the old name being a pure reference to the renamed attribute is added.
This means we have to add custom constructors, but we can change this
back to "= default" when the transition is completed, which should only
be a couple of CLs away.
Bug: webrtc:375048799
Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43300}
The FrameInstrumentationGenerator is responsible for generating the
instrumentation data that will be used to detect corruption. The data is
then passed to the encoder in the CodecSpecificInfo.
Bug: webrtc:358039777
Change-Id: I79d0534920b4c7fa001e1138371dfd36c13424fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362584
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43060}
The `requested_resolution` API must not change aspect ratio, example:
- Frame is 60x30
- Requested is 30x30
- We expect 30x15 (not 30x30!) as to maintain aspect ratio.
This bug was previously fixed by making VideoAdapter unaware of the
requested resolution behind a flag: this seemed OK since the
VideoStreamEncoder ultimately decides the resolution, whether or not
the incoming frame is adapted.
But this is not desired for some non-Chrome use cases. This CL attempts
to make both Chrome and non-Chrome use cases happy by implementing the
aspect ratio preserving restriction inside VideoAdapter too.
This allows us to get rid of the "use_standard_requested_resolution"
flag and change the "VideoStreamEncoderResolutionTest" TEST_P to
TEST_F.
Bug: webrtc:366067962, webrtc:366284861
Change-Id: I1dfd10963274c5fdfd18d0f4443b2f209d2e9a4b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362720
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43037}
When requested_resolution uses a different aspect ratio than the source
the encoder will restrict the frame without changing its aspect ratio,
e.g. a 60x30 input frame that is restricted to 30x30 results in 30x15,
not 30x30.
While this logic works correctly in isolation, if the source also adapts
the frame size based on the sink_wants.requested_resolution that is
signaled back to the source, then the source will produce stretched
30x30 prior to the encoder which happily sends 30x30 not knowing any
wiser.
This is incompatible with the spec[1] and makes this WPT[2] fail. The
correct behavior is to NOT signal the requested_resolution back to the
source, the encoder already configures the correct resolution so this
isn't actually needed and the source shouldn't need to know this API.
In order not to break downstream projects, the new behavior is landed
behind a flag and both behaviors are tested with TEST_P.
This unblocks launching scaleResolutionDownTo API on Web. Migrating
from old to new code path and deleting the flag is a follow-up AI:
webrtc:366284861.
[1] https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-scaleresolutiondownto
[2] https://chromium-review.googlesource.com/c/chromium/src/+/5853944
# Relying on previous green runs for confidence due to purple bots atm,
# see b/367211396
NOTRY=True
NOPRESUBMIT=True
Bug: webrtc:366067962, webrtc:366284861
Change-Id: I7fd1016e9cc6f0b0b9b8c23b0708e521f8e12642
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362541
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43024}
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}
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}
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}
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}
* 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}
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}
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}
Set is_steady_state_refresh_frame true if the update rectangle of the
corresponding VideoFrame is empty. Set it to false otherwise.
Rename FillTimingInfo to FillMetadataAndTimingInfo.
Bug: chromium:328598314
Change-Id: I7a3e89b180432473b087e849fce636ce1b329637
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355780
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42551}
The experiment has been disabled for several years and the code
is not maintained.
Bug: webrtc:42221141
Change-Id: I631e4bd476ca01eb5312d4077c9467e77c42ff78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/351143
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42364}
To allow various VideoBitrateAllocators to use propagated rather than global field trials
This relands the
https://webrtc-review.googlesource.com/c/src/+/349920
where patchset#1 is identical to the original change,
patchset#2 undoes (postpones) the expectation downstream propagates the Environment too.
Bug: webrtc:42220378
Change-Id: I4a9a32bb0926a875d37f3ba19dd5309e97546553
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350364
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42298}
To allow various VideoBitrateAllocators to use propagated rather than global field trials
Bug: webrtc:42220378
Change-Id: I52816628169a54b18a4405d84fee69b101f92f72
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349920
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42288}
Replace factory that takes optional FieldTrialView with a constructor that takes non-optional reference to the same interface - all callers already guarantee it is not nullptr
Replace several local IsEnabled/IsDisabled helpers with the same helpers in FieldTrialView
In CongestionWindowPushbackController tests pass field trials bypassing global field trial string
Bug: webrtc:42220378
Change-Id: Ic49ad78919d834a5e3b9b69545d3b39088023a75
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349900
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42270}
There is no TRACE_EVENT_ASYNC_STEP in the perfetto legacy API.
The corresponding legacy API that matches best is
TRACE_EVENT_ASYNC_STEP_INTO.
Bug: b/42226290
Change-Id: I6725973895878e34d96b6cd3314ab8de402a911b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349120
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42219}
This CL adds tracing support for input video frame representation
which was useful in debugging the linked bug.
Bug: b/328533258
Change-Id: I8a9e533b11d99688a71a24138bf8058b841e55d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348841
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Stefan Holmer <holmer@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42155}
These are required by the Perfetto API and the missing argument prevents
the use of Perfetto.
Bug: webrtc:15917
Change-Id: Ie40c0344dc9d8cd40f7c751b133d150b975a33c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347702
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#42147}
Instead of passing it as optional parameter during construction, pass field trials as required parameters on use.
Test that create the EncoderStreamFactory might not have an easy access to the actual field trials, but prod code has appropriate field trials when uses the factory.
This way EncoderStreamFactory doesn't need to depend on global field trial string through FieldTrialBaseConfig class.
Bug: webrtc:10335
Change-Id: I8f7030e41579ff2c5dd362c491a4e1624b23e690
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347700
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42098}
CropAndScale() makes offset_x and offset_y even if the U,V planes are
subsampled. This may result in the update rect being off by one. To
prevent that, always pass even offset_x and offset_y to CropAndScale().
Round the offset up when dividing crop size by 2 to make the cropping
more centered and symmetrical.
Note: The code was originally added in
https://webrtc-review.googlesource.com/c/src/+/123230.
Bug: webrtc:15910
Change-Id: I4a70d460702f03dee72a5b8292cb25766c3e6aca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346323
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Cr-Commit-Position: refs/heads/main@{#42052}
Instead of relying on the global field trial string
Bug: webrtc:10335
Change-Id: I491be089ffc725fd28483edf10eae4ae5d17d651
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346263
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42021}
Similar to the two RTC_CHECK_GE's earlier in the
VideoStreamEncoder::ReconfigureEncoder() method (originally added to
webrtc/video/vie_encoder.cc in
https://codereview.webrtc.org/2936393002), add two RTC_CHECK_GE's to
ensure that crop_width_ and crop_height_ are nonnegative.
Bug: b:330482827
Change-Id: Ia4989307b754abb101e50d33beeca4483a694a62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346026
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Cr-Commit-Position: refs/heads/main@{#42017}
This reverts commit d427e83a15ad2950095ce1d352cc7e11eaf6cad3.
Reason for revert: Flaky test fixed.
Refactor FrameCandenceAdapter to keep track of input frame rate. This fixes an issue where frame rate is calculated too low if congestion window drop a frame.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887, webrtc:15893
Change-Id: I76268aa0991dbc99c1b881fb251a76aa54ff2673
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344561
Reviewed-by: Erik Språng <sprang@google.com>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41972}
This reverts commit 784af1f42e89735587c442855fa01fc90475c449.
Reason for revert: Seems like test test_support_unittests
ResolutionAdaptsToAvailableBandwidth is flaky with this cl.
Original change's description:
> FrameCadenceAdapter keep track of Input framerate
>
> Refactor FrameCandenceAdapter to keep track of input frame rate.
>
> Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
> Uma is recorded to tell if input frame timestamp is monotonically increasing.
>
> Bug: webrtc:10481, webrtc:15887
> Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41967}
Bug: webrtc:10481, webrtc:15887
Change-Id: Id9672764768f2f40f8e711e990ad8ac18c28efcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344560
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41969}
Refactor FrameCandenceAdapter to keep track of input frame rate.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887
Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41967}
This reverts commit c39712b51522bb21c18c58c593f454c5cc0e7995.
Reason for revert: Fixed issue where frame rate not adapted to highest "active" requested frame rate.
Patchset 1 contains original cl.
Later patchsets contains modifications.
Original change's description:
> Propagate known Encoder SinkWants when configured instead of after first frame.
>
> Propagate requested resolution and max frame rate to the source when
> configured rather than after the first frame.
> This is so that the source can be configured immediately. There is no
> reason why source should be updated until after first frame since it may lead
> to unnecessary reconfigurations and thread jumps. Wants that depend on actual frame size is not moved.
>
> Cl also change default behaviour in VideoStreamEncoderTest to not
> set restriction on max frame rate.
>
Bug: webrtc:14451
Change-Id: I2668db44bd17586efcf511ad3cd975065c503ec5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343122
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41941}
This reverts commit 1ee24a650c116509d855e2ed23b8d28a0bb37384.
Reason for revert: Suspected upstream test breakage.
Original change's description:
> Propagate known Encoder SinkWants when configured instead of after first frame.
>
> Propagate requested resolution and max frame rate to the source when
> configured rather than after the first frame.
> This is so that the source can be configured immediately. There is no
> reason why source should be updated until after first frame since it may lead
> to unnecessary reconfigurations and thread jumps. Wants that depend on actual frame size is not moved.
>
> Cl also change default behaviour in VideoStreamEncoderTest to not
> set restriction on max frame rate. This aligns with how its used.
>
> Bug: webrtc:14451
> Change-Id: I96a3675d3ccabb1d2ecb4354b6932bc6563b1760
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342801
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41906}
Bug: webrtc:14451
Change-Id: I3aa669f8cc61a43b0820a06edf1497f3c86e3958
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343220
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41911}
Propagate requested resolution and max frame rate to the source when
configured rather than after the first frame.
This is so that the source can be configured immediately. There is no
reason why source should be updated until after first frame since it may lead
to unnecessary reconfigurations and thread jumps. Wants that depend on actual frame size is not moved.
Cl also change default behaviour in VideoStreamEncoderTest to not
set restriction on max frame rate. This aligns with how its used.
Bug: webrtc:14451
Change-Id: I96a3675d3ccabb1d2ecb4354b6932bc6563b1760
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342801
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41906}
VideoStreamEncoder creates VideoEncoders. To pass an Environment to VideoEncoder, it should be available in the VideoStreamEncoder.
Bug: webrtc:15860
Change-Id: Id89ac024ce61fdd9673bb66f03f94f243fc0c7f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341840
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41861}
A call to GetScalabilityMode was added for logging purpose and causes an expectation failure for tests using 4 temporal layers.
Plan is to remove the old GetScalabilityMode and keep only the one that returns an optional.
Change-Id: I0e37a496bb621d9754d6572ef5838b58193aa183
Bug: b/327381318
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341520
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#41838}
This is a reland of commit 050ffefd854f8a57071992238723259e9ae0d85a
Original change's description:
> Extends WebRTC logs for software encoder fallback
>
> This CL extends logging related to HW->SW fallbacks on the encoder
> side in WebRTC. The goal is to make it easier to track down the
> different steps taken when setting up the video encoder and why/when
> HW encoding fails.
>
> Current logs are added on several lines which makes regexp searching
> difficult. This CL adds all related information on one line instead.
>
> Three new search tags are also added VSE (VideoStreamEncoder), VESFW
> (VideoEncoderSoftwareFallbackWrapper) and SEA (SimulcastEncoderAdapter). The idea is to allow searching for the tags to see correlated logs.
>
> It has been verified that these added logs also show up in WebRTC
> logs in Meet.
>
> Logs from the GPU process are not included due to the sandboxed
> nature which makes it much more complex to add to the native
> WebRTC log. I think that these simple logs will provide value as is.
>
> Example: https://gist.github.com/henrik-and/41946f7f0b10774241bd14d7687f770b
>
> Bug: b/322132132
> Change-Id: Iec58c9741a9dd6bab3236a88e9a6e45440f5d980
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339260
> Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41733}
NOTRY=true
Bug: b/322132132
Change-Id: I25dd34b9ba59ea8502e47b4c89cd111430636e08
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339680
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41736}
This reverts commit 050ffefd854f8a57071992238723259e9ae0d85a.
Reason for revert: Breaks downstream project.
Original change's description:
> Extends WebRTC logs for software encoder fallback
>
> This CL extends logging related to HW->SW fallbacks on the encoder
> side in WebRTC. The goal is to make it easier to track down the
> different steps taken when setting up the video encoder and why/when
> HW encoding fails.
>
> Current logs are added on several lines which makes regexp searching
> difficult. This CL adds all related information on one line instead.
>
> Three new search tags are also added VSE (VideoStreamEncoder), VESFW
> (VideoEncoderSoftwareFallbackWrapper) and SEA (SimulcastEncoderAdapter). The idea is to allow searching for the tags to see correlated logs.
>
> It has been verified that these added logs also show up in WebRTC
> logs in Meet.
>
> Logs from the GPU process are not included due to the sandboxed
> nature which makes it much more complex to add to the native
> WebRTC log. I think that these simple logs will provide value as is.
>
> Example: https://gist.github.com/henrik-and/41946f7f0b10774241bd14d7687f770b
>
> Bug: b/322132132
> Change-Id: Iec58c9741a9dd6bab3236a88e9a6e45440f5d980
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339260
> Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41733}
Bug: b/322132132
Change-Id: I24d0a4e71a43ac192485f1af208563a51d919865
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339661
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41735}
