Since for such frame SvcController haven't setup how buffer should be
referenced and updated, the frame would likely have unexpected configuration.
Log an error to note resource have been wasted produce it and drop such frame.
Bug: webrtc:11999
Change-Id: I1784403e67b7207092d46016510460738994404e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205140
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33148}
Using WebRTC-VP9-PerformanceFlags and settings a multi-layer config,
and then configuring the codec in non-svc mode would cause us to not
set the cpu speed in libvpx. For some reason, that could trigger a
crash in the encoder.
This CL fixes that, and adds new test coverage for the code affected
byt the trial.
Bug: chromium:1167353, webrtc:11551
Change-Id: Iddb92fe03fc12bac37717908a8b5df4f3d411bf2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202761
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33051}
This adds a new way to poll decoder metadata.
A default implementation still delegates to the old methods.
Root call site is updates to not use the olds methods.
Follow-ups will dismantle usage of the olds methods in wrappers.
Bug: webrtc:12271
Change-Id: Id0fa6863c96ff9e3b849da452d6540e7c5da4512
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196520
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32976}
Also moves the LibvpxVp8Interface from codec/vp8 to codec/interface and
drops vp8 from the name.
Follow-up CLs will wire up actual usage in the new classes through the
interface so that we can unit test them more easily.
Bug: webrtc:12274
Change-Id: I95f66e90245d9320e5fc23cdc845fbeb2648b38b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196522
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32816}
This is a reland of 6e7167456b
Patch set 1 is the original.
Later patch sets fix a parsing bug, and adds a new flag which enables
or disabled the ability to set separate per spatial layer speed
(use_per_layer_speed).
Original change's description:
> Adds experimental libvpx VP9 speed settings.
>
> Using the field trial WebRTC-VP9-PerformanceFlags, this CL allows you to
> configure the libvpx VP9 encoder with a list of flags to affect the
> quality vs speed tradeoff. This CL adds support for:
>
> * Speed (effort), for the temporal base layer frames
> * Speed for higher (non-base) layer frames
> * De-blocking (as part of the loopfilter) enabled for:
> 0 = all frames
> 1 = all but frames from the highest temporal layer
> 2 = no frames
>
> Each entry in the list has a threshold in min number of pixels needed
> for settings in the entry to apply.
>
> Example: Two spatial layers (180p, 360p) with three temporal
> layers are configured. Field trial "WebRTC-VP9-PerformanceFlags" set to:
> "use_per_layer_speed,min_pixel_count:0|129600,base_layer_speed:5|7,high_layer_speed:8|8,deblock_mode:1|2"
> This translates to:
> S0:
> - TL0: Speed 5, deblocked
> - TL1: Speed 8, deblocked
> - TL2: Speed 8, not deblocked
> S1:
> - TL0: Speed 7, not deblocked
> - TL1: Speed 8, not deblocked
> - TL2: Speed 8, not deblocked
>
> Bug: webrtc:11551
> Change-Id: Ieef6816d3e0831ff53348ecc4a90260e2ef10422
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188461
> Reviewed-by: Michael Horowitz <mhoro@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32749}
Bug: webrtc:11551
Change-Id: Ie7c703eb122197235d8ce77cb72db7a347382468
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196345
Reviewed-by: Michael Horowitz <mhoro@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32780}
This reverts commit 6e7167456b.
Reason for revert: Unexpected perf change
Original change's description:
> Adds experimental libvpx VP9 speed settings.
>
> Using the field trial WebRTC-VP9-PerformanceFlags, this CL allows you to
> configure the libvpx VP9 encoder with a list of flags to affect the
> quality vs speed tradeoff. This CL adds support for:
>
> * Speed (effort), for the temporal base layer frames
> * Speed for higher (non-base) layer frames
> * De-blocking (as part of the loopfilter) enabled for:
> 0 = all frames
> 1 = all but frames from the highest temporal layer
> 2 = no frames
>
> Each entry in the list has a threshold in min number of pixels needed
> for settings in the entry to apply.
>
> Example: Two spatial layers (180p, 360p) with three temporal
> layers are configured. Field trial "WebRTC-VP9-PerformanceFlags" set to:
> "min_pixel_count:0|129600,base_layer_speed:5|8,high_layer_speed:7|8,deblock_mode:1|2"
> This translates to:
> S0:
> - TL0: Speed 5, deblocked
> - TL1: Speed 8, deblocked
> - TL2: Speed 8, not deblocked
> S1:
> - TL0: Speed 7, not deblocked
> - TL1: Speed 8, not deblocked
> - TL2: Speed 8, not deblocked
>
> Bug: webrtc:11551
> Change-Id: Ieef6816d3e0831ff53348ecc4a90260e2ef10422
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188461
> Reviewed-by: Michael Horowitz <mhoro@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32749}
TBR=sprang@webrtc.org,ssilkin@webrtc.org,mhoro@webrtc.org
Change-Id: If910963441ac1a0e002aac7066791c7cc7764a1a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11551
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196344
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32762}
Using the field trial WebRTC-VP9-PerformanceFlags, this CL allows you to
configure the libvpx VP9 encoder with a list of flags to affect the
quality vs speed tradeoff. This CL adds support for:
* Speed (effort), for the temporal base layer frames
* Speed for higher (non-base) layer frames
* De-blocking (as part of the loopfilter) enabled for:
0 = all frames
1 = all but frames from the highest temporal layer
2 = no frames
Each entry in the list has a threshold in min number of pixels needed
for settings in the entry to apply.
Example: Two spatial layers (180p, 360p) with three temporal
layers are configured. Field trial "WebRTC-VP9-PerformanceFlags" set to:
"min_pixel_count:0|129600,base_layer_speed:5|8,high_layer_speed:7|8,deblock_mode:1|2"
This translates to:
S0:
- TL0: Speed 5, deblocked
- TL1: Speed 8, deblocked
- TL2: Speed 8, not deblocked
S1:
- TL0: Speed 7, not deblocked
- TL1: Speed 8, not deblocked
- TL2: Speed 8, not deblocked
Bug: webrtc:11551
Change-Id: Ieef6816d3e0831ff53348ecc4a90260e2ef10422
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188461
Reviewed-by: Michael Horowitz <mhoro@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32749}
In particular move end_of_picture flag out of vp9 specific information
since VP9 is not the only codec that can use spatial scalability and
thus need to distinguish layer frame and picture (aka temporal unit).
Bug: webrtc:12167
Change-Id: I0d046d8785fbea55281209ad099738c03ea7db96
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/192542
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32588}
In the old jitter buffer the two VCMVideoProtection modes |kProtectionNone| and |kProtectionFEC| could be set on the jitter buffer for it to not wait for NACK and instead generate incomplete frames. This has not been possible for a long time.
Bug: webrtc:9378, webrtc:7408
Change-Id: I0a2d3ec34d721126c1128306d5fad88314f8d59f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/190680
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32513}
This changes the default behavior to use pacing factor of 1.1x instead
of 2.5x, it also sets libvpx rate controler as trusted, turns on the
encoder pushback mechanism and sets spatial hysteresis to 1.2.
The unused "dynamic rate" settings in libvpx is removed.
The new settings matches what has been used in chromium since 2019.
If needed, the legacy behavior can be enabled using the field trial
WebRTC-VideoRateControl.
Bug: webrtc:10155
Change-Id: I8186b491aa5bef61e8f568e96c980ca68f0c208f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186661
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32477}
Adds a field to EncoderInfo called preferred_pixel_formats which a
software encoder populates with the pixel formats it supports. When a
kNative frame is received for encoding, the VideoStreamEncoder will
first try to get a frame that is accessible by the software encoder in
that pixel format from the kNative frame. If this fails it will fallback
to converting the frame using ToI420.
This minimizes the number of conversions made in the case that the
encoder supports the pixel format of the native buffer or where
conversion can be accelerated. For example, in Chromium, the capturer can
emit an NV12 frame, which can be consumed by libvpx which supports NV12.
Testing: Tested in Chrome with media::VideoFrame adapters.
Bug: webrtc:11977
Change-Id: I9becc4100136b0c0128f4fa06dedf9ee4dc62f37
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187121
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#32353}
The trial name WebRTC-VP9-PerLayerSpeed is used to
a) set encoding speed per spatial layer, based on resolution
b) allow explicitly overriding speed per layer, for testing
Additionally, this CL updates the vp9 wrapper in preparation for
injectable trials.
Bug: webrtc:11551, webrtc:11926
Change-Id: I2bb3a664feaef60483ffc241b71070284d3e0172
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186400
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32294}
Otherwise if the pixel format is not I420, the image buffer will
need to be reallocated on each reconfiguration.
Bug: webrtc:11974
Change-Id: Ib13f1865d7dbba4635f57dc09c7bff846e127585
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186340
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#32281}
Before this change the allocated buffer and encoder complexity was set
based on the highest resolution configured regardless if that spatial
layer was active or not.
This should reduce memory pressure and improve visual quality when only
a low resolution is requested. In test, increasing the encoder
complexity has paradoxically also resulted in increased decoder speed.
Bug: webrtc:11551
Change-Id: I3ae47a5856de82ff7d40fddfcb160935b12b1d2b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186301
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32280}
NV12 frames can be encoded by libvpx now, and this change allows for
encoding of them with VP9.
VP9 encode/decode tests now run with NV12 as well as I420.
Manually tested using video loopback with VP9 and NV12 generated frames.
out/Default/video_loopback.app/Contents/MacOS/video_loopback --clip=GeneratorNV12 --codec="VP9"
Bug: webrtc:11635, webrtc:11974
Change-Id: Ifc5cbf77d2a27821cd5560c253d5d447c7a7cf53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/185123
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#32220}
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}
