While converting the aggregated (stap-a) packet transform packet
framing input into an annex-b framing copy, the two loops (both the
required size calculation and the stap-a-to-annex-b copy) may
over-read the input buffer.
In both buffers, `nalu_ptr` follows the input (stap-a) buffer, which
is located in `data`, and whose length is `data_size`. Buffer is read
until `nalu_ptr` reaches the end of the buffer. Issues is that the 5th
line in the loop:
```
uint16_t segment_length = nalu_ptr[0] << 8 | nalu_ptr[1];
```
This line accesses `nalu_ptr[1]`, which needs to be protected in
the loop condition. Let's assume `data_size = 4`, and that we restart
the loop with `nalu_ptr = data + 3`. The condition of the loop does
hold (`nalu_ptr = data + 3 < data + data_size`), but the 5th line
will access to `data[3+1] = data[4]`, which is an over-read.
Tested:
```
$ ninja -C out/Default
$ out/Default/modules_unittests --gtest_filter=PacketBuffer*:H264*:RtpPacketizerH264Test*:VideoRtpDepacketizerH264Test*:TestH264SpsPpsTracker* --logs
...
[ PASSED ] 97 tests.
```
Change-Id: I8b8aaf7d12b0bb154430b8922f099cd49e684762
Bug: webrtc:11698
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177140
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Niklas Enbom <niklas.enbom@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31561}
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}
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}
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 change introduces a new non-reentrant mutex to WebRTC. It
enables eventual migration to Abseil's mutex.
The mutex types supportable by webrtc::Mutex are
- absl::Mutex
- CriticalSection (Windows only)
- pthread_mutex (POSIX only)
In addition to introducing the mutexes, the CL also changes
PacketBuffer to use the new mutex instead of rtc::CriticalSection.
The method of yielding from critical_section.cc was given a
mini-cleanup and YieldCurrentThread() was added to
rtc_base/synchronization/yield.h/cc.
Additionally, google_benchmark benchmarks for the mutexes were added
(test courtesy of danilchap@), and some results from a pthread/Abseil
shootout were added showing Abseil has the advantage in higher
contention.
Bug: webrtc:11567, webrtc:11634
Change-Id: Iaec324ccb32ec3851bf6db3fd290f5ea5dee4c81
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176230
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31443}
This reverts commit 6958d2c6f0.
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}
to unblock rolling new version where private function is no longer available
Bug: None
Change-Id: I9c35fede3f331f7688cc97acfbda1250b42348a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176441
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31427}
This CL moves webrtc::NackModule to a deprecated folder and annotates
the type with RTC_DEPRECATED.
Since the header should not be used outside of WebRTC, this CL doesn't
created a forward header.
Bug: webrtc:11611
Change-Id: I4d5899d473d78b8c7f4a6a018e2805648244b5f1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176360
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31394}
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}
