1) Fix several typos and small mistakes which could lead to crashes
2) Adjust bitrates if leading layers are disabled
3) Wire up webrtc quality scaler
Bug: webrtc:11319
Change-Id: I16e52bdb1c315d64906288e4f2be55fe698d5ceb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177525
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31546}
enable this opt can give 20% performance improvement for video
decoding with 720P video loopback and fake camera on chromebook sarien.
Bug: None
Test: ./modules_tests on chromebook sarien
Change-Id: I8c6487b291b5861e6ba6b6d55b24d7ddb51c341e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177335
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31543}
This is a reland of d592575698
Patchset 2 is a reland of
https://webrtc-review.googlesource.com/c/src/+/177012
Patchset 3 is a fix for a potential crash when InitDecode()is called from
VideoStreamDecoderImpl::GetDecoder(), where the decoder_settings
parameter is a but surprisingly set to nullptr.
Original change's description:
> VP9 decoder: Sets thread count based on resolution, reinit on change.
>
> Previously, number of decoder threads for VP9 were always set to 8 but
> with a cap at number of cores. This was done since we "can't know" the
> resolution that will be used.
>
> With this change, we now intialize the number of threads based on
> resolution given in InitDecode(). If a resolution change happens in
> flight, it requires a keyframe. We therefore parse the header from
> any key frame and if it has a new resolution, we re-initialize the
> decoder.
>
> The number of threads used is based on pixel count. We set one thread
> as target for 1280x720, and scale up lineraly from there. The 8-thread
> cap is gone, but still limit it core count.
>
> This means for instance: 1 <= 720p, 2 for 1080p, 4 for 1440p, 9 for 4K.
>
> Bug: webrtc:11551
> Change-Id: I14c169a6c651c50bd1b870c4b22bc4495c8448fd
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174460
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31507}
Bug: webrtc:11551
Change-Id: I2b4b146d0b8319f07ce1660202d6aa4b374eb015
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177246
Reviewed-by: Johannes Kron <kron@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31527}
Show it can make vp9 tests cleaner too.
Bug: None
Change-Id: I8333a61dec1ef90ade9faffea94e1555ccbfcfaa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177013
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31523}
This reverts commit d592575698.
Reason for revert: May cause crashes.
Original change's description:
> VP9 decoder: Sets thread count based on resolution, reinit on change.
>
> Previously, number of decoder threads for VP9 were always set to 8 but
> with a cap at number of cores. This was done since we "can't know" the
> resolution that will be used.
>
> With this change, we now intialize the number of threads based on
> resolution given in InitDecode(). If a resolution change happens in
> flight, it requires a keyframe. We therefore parse the header from
> any key frame and if it has a new resolution, we re-initialize the
> decoder.
>
> The number of threads used is based on pixel count. We set one thread
> as target for 1280x720, and scale up lineraly from there. The 8-thread
> cap is gone, but still limit it core count.
>
> This means for instance: 1 <= 720p, 2 for 1080p, 4 for 1440p, 9 for 4K.
>
> Bug: webrtc:11551
> Change-Id: I14c169a6c651c50bd1b870c4b22bc4495c8448fd
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174460
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31507}
TBR=ilnik@webrtc.org,sprang@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:11551
Change-Id: Id235c8ded83b3e1fc1d132c8f56c9f20001f6f22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177242
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31521}
This reverts commit 26e5046951.
Reason for revert: Part of change that may cause crashes.
Original change's description:
> Adjusts allowable thread count for vp9 decoders.
>
> Set 2 thread as target for 1280x720 pixel count, and then scale up
> linearly from there - but cap at physical core count.
> For common resolutions this results in:
> 1 for 360p
> 2 for 720p
> 4 for 1080p
> 8 for 1440p
> 18 for 4K
>
> Bug: webrtc:11551
> Change-Id: I666bd971eccddee096749f20d3b08eb40fe868ad
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177012
> Reviewed-by: Johannes Kron <kron@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31513}
TBR=sprang@webrtc.org,kron@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:11551
Change-Id: I4ea5166efeed3d55255a0243a69deb584a0e19e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177240
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31517}
Set 2 thread as target for 1280x720 pixel count, and then scale up
linearly from there - but cap at physical core count.
For common resolutions this results in:
1 for 360p
2 for 720p
4 for 1080p
8 for 1440p
18 for 4K
Bug: webrtc:11551
Change-Id: I666bd971eccddee096749f20d3b08eb40fe868ad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177012
Reviewed-by: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31513}
Previously, number of decoder threads for VP9 were always set to 8 but
with a cap at number of cores. This was done since we "can't know" the
resolution that will be used.
With this change, we now intialize the number of threads based on
resolution given in InitDecode(). If a resolution change happens in
flight, it requires a keyframe. We therefore parse the header from
any key frame and if it has a new resolution, we re-initialize the
decoder.
The number of threads used is based on pixel count. We set one thread
as target for 1280x720, and scale up lineraly from there. The 8-thread
cap is gone, but still limit it core count.
This means for instance: 1 <= 720p, 2 for 1080p, 4 for 1440p, 9 for 4K.
Bug: webrtc:11551
Change-Id: I14c169a6c651c50bd1b870c4b22bc4495c8448fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174460
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31507}
This is more logical way to remove inactive lower layers.
Current way is to notify the encoder that the layer is inactive,
then renumber layers at the packatization level.
This Cl will allow to simplify libvpx vp9 encoder, svcRateAllocator and
vp9 packetizer.
Bug: webrtc:11319
Change-Id: Idf0bb30b729f5ecc97e31454b32934546b681aa2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173182
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31058}
This CL fixes a few issues where the reported fraction of frames
allocated to various temporal layers could be incorrect:
* In LibvpxVp8Encoder, calling GetEncoderInfo() while not initialized,
or when first configuring with temporal layers and then without,
could trigger incorrect fps allocations.
* In VP9 when different spatial layers have different max framerates,
the layer fps should be compared to the layer with the highest
configured fps, not codec_.maxFramerate which is updated to the
current input fps on SetRates().
* In EncoderBitrateAdjuster, just warn and ignore if a layer has
non-zero bps but zero fps, rather than passing down the chain and
risk weird behavior or divide by zero.
Bug: b/152040235
Change-Id: I548fb3e099b1ec9f536a7b93313fb40c4d32e596
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171516
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30880}
~3-5% speed up on webrtc_perf_tests of vp9 on linux desktop.
Avoid going thru a lot of unnecessary code checks.
Change-Id: I2cb0d794bcf239c5057dfc04cd07a496f89a5016
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167640
Commit-Queue: Jerome Jiang <jianj@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30586}
If e.g. CPU adaptation reduces input video size too much, video pipeline would
reduce the number of used simulcast streams/spatial layers. This may result in
disabled video if some streams are disabled by Rtp encoding parameters API.
Bug: webrtc:11319
Change-Id: Id7f157255599dcb6f494129b83477cda4bea982a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168480
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30498}
This CL uses |width| and |height| in RTPVideoHeaderVP9 to pass information
about enabled layers from encoder to packetizer.
Bug: webrtc:11319
Change-Id: Idc1c337f8dfb3f7631506acb784d2a634b41b955
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167724
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30428}
Chromting is trying vp9 444 to have better color. This fix is needed to decode 444 properly.
Bug: webrtc:11326
Change-Id: I4498930591d8876af9f6b7238a8c9fe450ecbfcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166220
Commit-Queue: Jerome Jiang <jianj@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30410}
This CL was generated by running:
git ls-files | grep ".cc" | xargs perl -i -ne 'BEGIN {undef $/}; s/("[\s\n]*<<[\s\n]*")/" "/g; print;'; git cl format
After that I manually edited modules/audio_processing/gain_controller2.cc to preserve its original
formatting.
This primary benefit of this change is a small reduction in binary size.
Bug: None
Change-Id: I689fa7ba9c717c314bb167e5d592c3c4e0871e29
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165961
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30251}
Now vp9 screenshare would enable new layers as soon as requested and will force all spatial layers present on the next frame, even if they should be dropped because of frame-rate limiting.
This might cause frame-rate liming to be exceeded if layer is toggling on and off very often, but this situation is bad itself. E.g. in realtime video it will cause too many key-frames.
Now SvcRateAllocator and VP9EncoderImpl are aware that there may be some skipped layers before the first enabled. Key-frames and ss_info triggering logic is also updated.
(This is a reland without changes after updates to downstream projects)
Original-Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153483
Bug: webrtc:10977
Change-Id: I02459c5982da2e0542a837514f5753c5f96401c6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154355
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29330}
This reverts commit 88fe84b7fb.
Reason for revert: Downstream project isn't updated to the latest libvpx roll yet, thus some tests are broken.
Original change's description:
> VP9 encoder: handle disabled layers correctly
>
> Now vp9 screenshare would enable new layers as soon as requested and will
> force all spatial layers present on the next frame, even if they should be
> dropped because of frame-rate limiting.
>
> This might cause frame-rate liming to be exceeded if layer is toggling on
> and off very often, but this situation is bad itself. E.g. in realtime video
> it will cause too many key-frames.
>
> Now SvcRateAllocator and VP9EncoderImpl are aware that there may be some skipped
> layers before the first enabled. Key-frames and ss_info triggering logic is also
> updated.
>
> Bug: webrtc:10977
> Change-Id: Ie2555210c0368a1d3c51ddf6670d0052e6d679de
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153483
> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29296}
TBR=ilnik@webrtc.org,ssilkin@webrtc.org
Change-Id: If33886a5f8a0c3b33168dcadfe45c11a6f4387c1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10977
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154354
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29299}
Now vp9 screenshare would enable new layers as soon as requested and will
force all spatial layers present on the next frame, even if they should be
dropped because of frame-rate limiting.
This might cause frame-rate liming to be exceeded if layer is toggling on
and off very often, but this situation is bad itself. E.g. in realtime video
it will cause too many key-frames.
Now SvcRateAllocator and VP9EncoderImpl are aware that there may be some skipped
layers before the first enabled. Key-frames and ss_info triggering logic is also
updated.
Bug: webrtc:10977
Change-Id: Ie2555210c0368a1d3c51ddf6670d0052e6d679de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153483
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29296}
Passing an empty arg is working at the moment but it is not
guaranteed to continue to work in the future.
This CL has been generated with:
git grep -l "INSTANTIATE_TEST_SUITE_P(," | xargs sed -i \
"s/INSTANTIATE_TEST_SUITE_P(,/INSTANTIATE_TEST_SUITE_P(All,/g"
Bug: None
Change-Id: Icd2fb9d9d29aed5d692a234124bd990d0f097db4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153890
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29282}
This mode was added by libvpx team specificaly for this usecase: if a
layer is dropped, all lower layers have to be dropped also.
This ensures that higher layers always have higher framerate than the
lower layers and stream is RTP compatible.
This CL also renames full_superframe_drop_ to !layer_buffering, as it
closer reflects the purpose of that flag (in screenshare mode, no
buffering is needed, because the highest layer is always present in the
superframe, yet, it's not a full-superframe dropping mode).
Bug: webrtc:10257
Change-Id: I2589bfd2b9b63de0e410f277a716276234993843
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151764
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29155}
if higher layer is enabled, then disabled, then key-frame is issued, then
the layer is enabled again, the buffer would contain a picture from before
the key-frame and it might have a higher pid than the currently encoded one.
This would trigger the DCHECK. It's safe to remove the DCHECK completely, because
such occasions would cause unsigned overflow and cause the following check for
maximum allowed picture difference to fail and the wrong picture won't
be used as a temporal reference.
This error only caused failures in debug builds and couldn't lead to corruptions
because there're periodical key-frames generated and pid difference can never become so
big that negative value would overflow to something close to 0.
Bug: webrtc:10257
Change-Id: Ie3b3ed0e24421787e3b40a37987ccecb75d04635
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151643
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29099}
