which needs to be added to the remote codecs a=fmtp:
This also forces SimulcastCastEncoderAdapter to avoid issues with codecs that have native simulcast capability but do require synchronized keyframes.
This parameter allows for large-scale experimentation and A/B testing
whether the new behavior has advantages. It is to be considered
transitional and may be removed again in the future.
BUG=webrtc:10107
Change-Id: I81f496c987b2fed7ff3089efb746e7e89e89c033
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/333560
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41805}
kDefaultQpMax=56 was defined in multiple places. Move it to media_constants and split it into two: VPx/AV1 and H26x values. H26x value is set to 51 which is the max bitstream QP value for H264/5.
This CL is expected to be a no-op because:
1. VideoCodec::qpMax value has not changed for VP8/9 and AV1.
2. VideoCodec::qpMax is currently not used by OpenH264 wrapper (wiring it up is out-of-scope of this CL).
3. Previous default qpMax=56 exceeded the max value for H26x (=51). External HW H26x encoders likely clamped it and used 51.
Bug: webrtc:14852
Change-Id: I1d795e695dac5c78e86ed829b24281e61066f668
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324282
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40997}
Convert most field trials used in PCLF tests.
Change-Id: I26c0c4b1164bb0870aae1a488942cde888cb459d
Bug: webrtc:10335
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322703
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40909}
Attempting to ship "WebRTC-AllowDisablingLegacyScalability" revealed a
DCHECK that happens when negotiating 3 VP9 streams prior to the
setParameters() call:
1. By default, `scalability_mode` is missing, so those 3 streams
defaulted to legacy SVC, meaning only a single stream is used.
2. Then, setParameters() was called to make
`encodings[0].scalability_mode = "L2T2_KEY"` and
`encodings[1-2].active = false`. The inactive streams were just
dummies and never expected to exist.
Without simulcast support this is OK, because both 1) and 2) are
interpreted to have a single stream. But with simulcast support, 1) is
interpreted as single stream and 2) as three streams (1 active, 2
inactive). This should be roughly the same setup, but our code treats
them differently.
The DCHECK crash was a mismatch in number of streams in one of the
layers.
The fix is to re-create the streams when the number of streams change
for this reason. The new test revealed other issues and fixes too:
- Support for multiple spatial layers (e.g. "L2T2_KEY") when multiple
encodings exist but only one encoding is active.
- Allow inactive layers not to have a scalability mode set.
A laundry list (https://crbug.com/webrtc/15028) has been created to
update known places doing "if streams == 1" that need to do "if
active streams == 1" instead.
Credit:
The RecreateWebRtcStream() fix is based on eshr@'s POC from
https://webrtc-review.googlesource.com/c/src/+/298565.
Bug: webrtc:15016
Change-Id: I909a3f83a4ef53562894549ade0a870b208cec7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298443
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#39651}
As part of go/unblocking-vp9-simulcast (Step 1), EncodedImage is being
upgraded to be able to differentiate between what is a simulcast index
and what is a spatial index.
In order not to break existing code assuming that "if codec != VP9,
SpatialIndex() is the simulcast index", SimulcastIndex() has fallback
logic to return the value of spatial_index_ in the event that
SetSimulcastIndex() has not been called. This allows migrating external
code from (Set)SpatialIndex() to (Set)SimulcastIndex(). During this
intermediate time, codec gates are still necessary in some places of
the code, see TODOs added.
In a follow-up CL, after having fixed dependencies, we'll be able to
remove the fallback logic and rely on SimulcastIndex() and
SpatialIndex() actually being the advertised index and "if codec..."
hacks will be a thing of the past!
Bug: webrtc:14884
Change-Id: I70095c091d0ce2336640451150888a3c3841df80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293343
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39318}
At the same time, proper names of some parameters are refactored in SimulcastEncoderAdapter.
Bug: None
Change-Id: Ia036e3f362d1394e90aa26b79953c1ffe75e2fe0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/284961
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Chunbo Hua <chunbo.hua@intel.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38870}
Passes frame_types to the underlying encoder in bypass mode.
For libvpx this has no effect, for H264 this changes the behavior
to allow generating keyframes on a per-layer basis.
BUG=chromium:1354101
Change-Id: I26fc22d9e2ec4681a57ce591e9eafd0b1ec962b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285083
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#38821}
in the case of separate encoders.
drive-by: add helper function to expect per-layer keyframes
BUG=chromium:1354101
Change-Id: Ib645a621add899f035bea319f035dcb0b2617510
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281002
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#38734}
Step one in making it a separate type, that will be done as a
followup, after downstream code is updated to use the new name.
Bug: webrtc:11607
Change-Id: I6fa664a0729b1cfd71b7f02b6441880beee0e741
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262806
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36946}
Move complexity parameter to the main VideoCodec class to enable
additional video codecs to use the parameter without creating a new
codec-specific structure.
Bug: webrtc:13694
Change-Id: Icb7cf640b178875d799f39ade8b5084e3222bb1c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251921
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Michael Horowitz <mhoro@google.com>
Cr-Commit-Position: refs/heads/main@{#36040}
`a && b` only evaluates b if a is true. `a & b` always evaluates
both a and b. If a and b are of type bool, `&&` is usually what you
want, so clang now warns on `&` when both arguments are of type bool.
In the one case where this fires in webrtc, it isn't important if we
evaluate both branches, so I went with `&&`.
Bug: chromium:1255745
Change-Id: I7fd215778fca62e0d5ca64ab0cf1142942eb7304
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234600
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35181}
In case if primary encoder can't be instantiated (max number of
instances has reached, for example), use fallback encoder.
Bug: none
Change-Id: I477bdeb7af4dcce50e36b1804ffc6ad2ab004dfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234500
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35161}
On the Android and iOS platforms, occasionally crash when using the SimulcastEncoderAdapter.
The Android platform reverted,
In function `SimulcastEncoderAdapter::EncoderContext::Release`,
After executing `encoder_->RegisterEncodeCompleteCallback(nullptr)`
before execute `encoder_->Release()`
If the encoder thread is executed here,
```
// out/xxx/xxx/gen/sdk/android/generated_video_jni/VideoEncoderWrapper_jni.h
JNI_GENERATOR_EXPORT void Java_org_webrtc_VideoEncoderWrapper_nativeOnEncodedFrame(
JNIEnv* env,
jclass jcaller,
jlong nativeVideoEncoderWrapper,
jobject frame) {
VideoEncoderWrapper* native = reinterpret_cast<VideoEncoderWrapper*>(nativeVideoEncoderWrapper);
CHECK_NATIVE_PTR(env, jcaller, native, "OnEncodedFrame");
return native->OnEncodedFrame(env, base::android::JavaParamRef<jobject>(env, frame)); // HERE
}
```
it will cause `native` to nullptr.
iOS also.
Bug: webrtc:13156
Change-Id: Id5563b3fa2c11606ae7b35de56bbaa6adba59b14
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231780
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34989}
Some hardware H.264 encoders does not place average QP delta in
slice_qp_delta field. Adding an optional flag in EncoderInfo to notify
quality scaler about this.
Bug: webrtc:12942
Change-Id: I3ee29c5ae9bd7bb34d26eba7e6bede3798ca44b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226921
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34627}
Software fallback wrapper now reports least common multiple of requirements
for two encoders.
SimulcastEncoderAdapter queries actual encoder before InitEncode call
and requests alignment for all layers if simulcast is not supported by
any of the encoders.
Bug: chromium:1084702
Change-Id: Iaed8190737125d447036b6c664b863be72556a5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225881
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34466}
With this CL, SimulcastEncoderAdapter no longer configures its encoder
as multi-layered if we only have a single active layer. Instead we
create a single single-layered encoder for that one and only active
layer. When using VP8 SW encoder this means that LibvpxVp8Encoder is
configured to only prepare a single video frame which avoids the cost of
scaling down to layers that we do not send. (A multi-layered
LibvpxVp8Encoder is required to scale even layers we don't encode.)
When profiling this CL I found very small but measurable gains for
representative downscale factors of 20.1 ms of 60 s profile. This is
just 0.0335% CPU so it's not much, but skipping a downscale might be
worth a lot more if we have to map/unmap buffers or do GPU round-trips
in the future (which I have not measured).
When downscaling to factors 4 and 2 due to libyuv having a
"fast-path" for these (i.e. no adaptation active), zero difference was
found for NV12. For I420 there was small regression of 16.1 ms
(0.026% CPU) for this one edge-case. It's possible to work around this,
but considering the tiny changes we're talking about, I really don't
think it's worth the additional complexity. I'll file a bug on libyuv
about scaling factors 2+2 vs 4 and leave it at that.
Bug: webrtc:12603
Change-Id: Id462140c6a829cf6b460baae868e94243f477db3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219683
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34092}
Added class EncoderInfoSettings for parsing settings.
Added use of class to SimulcastEncoderAdapter.
Bug: none
Change-Id: I8182b2ab43f0c330ebdf077e9f7cbc79247da90e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202246
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33050}
This sincludes the SimulcastEncoderAdapter and the
VideoEncoderSoftwareFallbackWrapper. This avoids converting
the frame when that is not needed.
Bug: webrtc:11976
Change-Id: I686725ecfb79c3b8d87d587a907da1602483bfe8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187343
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#32389}
This is a reland of 32ca95145c
Fix includes not enabling the screenshare conference behavior on non
screenshare sources even if the flag is enabled.
Original change's description:
> Only enable conference mode simulcast allocations with flag enabled
>
> Non-conference mode simulcast screenshares were mistakenly using the
> conference mode semantics in the simulcast rate allocator, which broke
> spec compliant usage in some situation.
>
> This behavior should only be used when explicitly using the SDP entry
> "a=x-google-flag:conference" in both offer and answer.
>
> Bug: webrtc:11310, chromium:1093819
> Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31828}
Bug: webrtc:11310
Bug: chromium:1093819
Change-Id: Ic933f93a5c4bad20583354fe821f8a1170e911cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180802
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31847}
This reverts commit 32ca95145c.
Reason for revert: Internal test failure
Original change's description:
> Only enable conference mode simulcast allocations with flag enabled
>
> Non-conference mode simulcast screenshares were mistakenly using the
> conference mode semantics in the simulcast rate allocator, which broke
> spec compliant usage in some situation.
>
> This behavior should only be used when explicitly using the SDP entry
> "a=x-google-flag:conference" in both offer and answer.
>
> Bug: webrtc:11310, chromium:1093819
> Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31828}
TBR=ilnik@webrtc.org,hta@webrtc.org,orphis@webrtc.org
Change-Id: I5ccb6e87594f491ba09fe6b837ee24d63db878ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11310
Bug: chromium:1093819
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180801
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31829}
Non-conference mode simulcast screenshares were mistakenly using the
conference mode semantics in the simulcast rate allocator, which broke
spec compliant usage in some situation.
This behavior should only be used when explicitly using the SDP entry
"a=x-google-flag:conference" in both offer and answer.
Bug: webrtc:11310, chromium:1093819
Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31828}
Also, make sure active flags are not lost in simulcast encoder adapter
which is needed in case of simulcast encoder adapter is used.
VP9 libvpx encoder currently ignores scaling setting for SVC, but libvpx
fix is incoming.
TESTED=On a manually patched chrome with singlecast-simulcast vp8 stream.
Bug: webrtc:11396
Change-Id: Ic81f014bec1bdaaf6d5d173743933e5d77d71ea2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169547
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30681}
This CL makes native the preferred buffer type, and if any of the
encoders in the adapter do not support native, the input frame will
be converted to I420 and used as input to encoders that require it,
along with any needed downscaling.
Bug: chromium:1052352
Change-Id: Iff43d6dc56793037a6164729b9e6c69797b6f8cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168609
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30565}
If in simulcast case some streams are disabled (especially the first one), the key-frame
requests might be ignorred by e.g. libvpx vp8 encoder wrapper.
Before this CL SimulcastEncoderAdapter always passes single frame type in Encode() call.
However, if underlying encoder used simulcast, it would've expected as many frame types
as there are streams.
Bug: none
Change-Id: I7f56a6540b67273b7d3cf9fa86dc76015b92d271
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165681
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30210}
There are edge cases where the caching of encoder info will cause
issues. For instance if a sub-encoder fails en Encode call and falls
back to some other implementation, or if the fps targets shift due to
SetRates() triggering new layers to be enabled.
This CL forces a complete rebuild on every call to GetEncoderInfo().
It also adds new logging of when the info changes, as debugging issues
can be very time consuming if we can't tell that happened.
Bug: webrtc:11000
Change-Id: I7ec7962a589ccba0e188e60a11f851c9de874fab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160960
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29938}
