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 d5925756980f6e82a55f57532c8d855e954459fb
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}
Params and format is the same as for existing ARM experiment, but a new
group name is created for non-ARM experiment.
Bug: webrtc:11551
Change-Id: I3a6c0f07a8c1d714477ae4703c16e48df36ac10e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177102
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31524}
This reverts commit d5925756980f6e82a55f57532c8d855e954459fb.
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 26e50469513a3df2abb88c9ae2a5af70de0b029c.
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 reverts commit 6958d2c6f0ce5267bdc4120d88680a4be9ed5e59.
Disable the test on iOS.
Bug: None
Change-Id: Ie42fada10a92bd4a802c6c79caeb4965410ddf6a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176461
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Jerome Jiang <jianj@google.com>
Cr-Commit-Position: refs/heads/master@{#31437}
Use speed 6 for better quality for low resolution, speed 8 for HD for better speed.
This will better balance speed and quality.
Change-Id: I3d8dbd45533471ce58d53c1ac26f92c7b1106259
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175281
Reviewed-by: Marco Paniconi <marpan@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Jerome Jiang <jianj@google.com>
Cr-Commit-Position: refs/heads/master@{#31336}
Max encoder bitrate in WebRTC and OpenH264 are different settings. In
WebRTC it is a cap for encoder target bitrate whilst in OpenH264 it is
a peak bitrate. I.e. OpenH264 is allowed to produce bitrate up to
iMaxBitrate for short time interval. That is not what WebRTC expects.
https://webrtc.googlesource.com/src/+/5ee6967c4edc667688d736c27db6f2e7be00dd0a
disabled encoders re-initialization on min/max bitrate change. Reinit of
some HW encoders takes hundreds of milliseconds and causes video freeze.
I missed that max bitrate is used by OpenH264. This caused regression
described in webrtc:11543.
This change sets iMaxBitrate=UNSPECIFIED_BIT_RATE (which is the default
value). Settings iMaxBitrate=UNSPECIFIED_BIT_RATE disables the frame
dropping logic based on that parameter. But the encoder still will drop
frames based on buffer fullness, https://source.chromium.org/chromium/chromium/src/+/master:third_party/openh264/src/codec/encoder/core/src/ratectl.cpp;l=806-807
Bug: webrtc:10773, webrtc:11543
Change-Id: I728be49e0df8a0d9a8f4438299e4c7b4c1497a78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174745
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31192}
while helpful by itself, it is also a preparation
for adding unittests for (to be added) svc features of the encoder.
Bug: webrtc:11404
Change-Id: I62b0645f44579f21f228d406a206b4c01d80dd02
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174580
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31189}
