Before this CL quality scaling was conditioned on scaling settings
provided by encoder. That should not be a requirement since encoder
may not be aware of quality scaling which is a WebRTC feature. In M90
chromium HW encoders do not provide scaling settings (chromium:1179020).
The default scaling settings provided by these encoders are not correct
(b/181537172).
This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
is set to true in singlecast with normal video feed (not screen sharing)
mode. If quality scaling is allowed it is enabled no matter whether
scaling settings are present in encoder info or not. Setting from
QualityScalingExperiment are used in case if not provided by encoder.
Bug: chromium:1179020, webrtc:12511
Change-Id: I83d55319ce4b9f4fb143187ced94a16a778b4de3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209184
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33373}
Check if codec was successfully created and exit from RunTest if not
before creating VideoProcessor.
Bug: none
Change-Id: Ia6d7171650dbc9824fb78f4a8e2851f755cfd63b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209362
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33372}
The new verification makes verification a function on a message.
It also stores the password used in the request message, so that
it is easily accessible when verifying the response.
Bug: chromium:1177125
Change-Id: I505df4b54214643a28a6b292c4e2262b9d97b097
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209060
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33366}
This gets rid of the SctpTransportMap::Retrieve method and forces
everything to go through PostToTransportThread, which behaves safely
with relation to the transport's destruction.
Bug: webrtc:12467
Change-Id: Id4a723c2c985be2a368d2cc5c5e62deb04c509ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208800
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33364}
This is a reland of a37f2bd9421868e222d591d3371486a6ab939fd6
Original change's description:
> Rename SIGNALING and WORKER to PRIMARY and SECONDARY
>
> This makes the proxy macros less confusing when the secondary thread
> is sometimes the worker thread, sometimes the networking thread.
>
> Bug: none
> Change-Id: I1a8cebb82d09be44fe40e80c861bcfb47b9928e8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208763
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33346}
Bug: none
Change-Id: If46a6679ac0fc947797dd7be87626ef7702faca2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208845
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33349}
This makes the proxy macros less confusing when the secondary thread
is sometimes the worker thread, sometimes the networking thread.
Bug: none
Change-Id: I1a8cebb82d09be44fe40e80c861bcfb47b9928e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208763
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33346}
According to our previous data from trace_event with using direct memcpy
and libyuv::CopyPlane on chromebook atlas, the average cpu duration is
0.624ms and 0.541ms, so using libyuv::CopyPlane is 13.3% faster than
direct memcpy.
Bug: webrtc:12496
Change-Id: I1c41424b402a7eec34052c67933f2e88eaf0a8f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196485
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33344}
This will allow us to optimize the internal buffers of
webrtc::VideoFrame for the resolution(s) that we actually want to
encode.
Bug: webrtc:12469, chromium:1157072
Change-Id: If378b52b5e35aa9a9800c1f7dfe189437ce43253
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208540
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33342}
This reverts commit cd5127b11e04b7f49031b2412625c36e4a86c3da.
Reason for revert: Fuzzer build problems fixed.
Original change's description:
> Revert "Enable use of rtc::SystemTimeNanos() provided by Chromium"
>
> This reverts commit dfe19719e53abfd4d73722942445c5e1046b671b.
>
> Reason for revert: Breaks fuzzers in Chromium builds. See https://ci.chromium.org/ui/p/chromium/builders/try/linux-libfuzzer-asan-rel/685438/overview. I am reverting since this blocks the roll but I will be in touch for a fix.
>
> Original change's description:
> > Enable use of rtc::SystemTimeNanos() provided by Chromium
> >
> > This is the third CL out of three to enable overriding
> > of the function SystemTimeNanos() in rtc_base/system_time.cc
> >
> > When WebRTC is built as part of Chromium the rtc::SystemTimeNanos()
> > function provided by Chromium will be used. This is controlled
> > by the build argument rtc_exclude_system_time which directly
> > maps to the macro WEBRTC_EXCLUDE_SYSTEM_TIME.
> >
> > By doing this we are making sure that the WebRTC and Chromium
> > clocks are the same.
> >
> > Bug: chromium:516700
> > Change-Id: If7f749c4aadefb1cfc07ba4c7e3f45dc6c31118b
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208223
> > Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> > Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33337}
>
> TBR=kron@webrtc.org
>
> Bug: chromium:516700
> Change-Id: I9ecd1784a6c1cdac8bae07d34f7df20c62a21a95
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208740
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33340}
Bug: chromium:516700
Change-Id: I4cd68bac1cc4befdb46351f5d6fb2cf1ef5c3062
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208742
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33341}
This reverts commit dfe19719e53abfd4d73722942445c5e1046b671b.
Reason for revert: Breaks fuzzers in Chromium builds. See https://ci.chromium.org/ui/p/chromium/builders/try/linux-libfuzzer-asan-rel/685438/overview. I am reverting since this blocks the roll but I will be in touch for a fix.
Original change's description:
> Enable use of rtc::SystemTimeNanos() provided by Chromium
>
> This is the third CL out of three to enable overriding
> of the function SystemTimeNanos() in rtc_base/system_time.cc
>
> When WebRTC is built as part of Chromium the rtc::SystemTimeNanos()
> function provided by Chromium will be used. This is controlled
> by the build argument rtc_exclude_system_time which directly
> maps to the macro WEBRTC_EXCLUDE_SYSTEM_TIME.
>
> By doing this we are making sure that the WebRTC and Chromium
> clocks are the same.
>
> Bug: chromium:516700
> Change-Id: If7f749c4aadefb1cfc07ba4c7e3f45dc6c31118b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208223
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33337}
TBR=kron@webrtc.org
Bug: chromium:516700
Change-Id: I9ecd1784a6c1cdac8bae07d34f7df20c62a21a95
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208740
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33340}
This is the third CL out of three to enable overriding
of the function SystemTimeNanos() in rtc_base/system_time.cc
When WebRTC is built as part of Chromium the rtc::SystemTimeNanos()
function provided by Chromium will be used. This is controlled
by the build argument rtc_exclude_system_time which directly
maps to the macro WEBRTC_EXCLUDE_SYSTEM_TIME.
By doing this we are making sure that the WebRTC and Chromium
clocks are the same.
Bug: chromium:516700
Change-Id: If7f749c4aadefb1cfc07ba4c7e3f45dc6c31118b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208223
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33337}
Apart from making the map smaller, a purpose of this is guaranteeing
that if a module has been deactived it will not receive new packets
from the pacer, which will be needed for deferred sequencing.
Bug: webrtc:11340
Change-Id: I171a13413c5b8d3fa569c2d56bd9a54bff7c7976
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208542
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33335}
Sometimes c2.qti.vp8.decoder reports format updates with zero frame
width / height right after initialization, that leads to the
precondition check failure made by SurfaceTextureHelper.setTextureSize.
This patch makes AndroidVideoDecoder.reformat to ignore such format
updates so as to continue to use this HW decoder.
It seems to be safe because this decoder singals one more format update
with valid dimensions soon and continue to operate in normal mode.
Bug: webrtc:12492
Change-Id: I5155166637bd2d4247d31e608d714e687e0ad1df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208222
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33332}
The low-latency renderer is activated by the RTP header extension
playout-delay if the min value is set to 0 and the max value is
set to something greater than 0.
According to the specification of the playout-delay header
extension it doesn't have to be set for every frame but only if
it is changed. The bug that this CL fixes occured if a playout
delay had been set previously but some frames without any specified
playout-delay were received. In this case max composition delay
would not be set and the low-latency renderer algorithm would be
disabled for the rest of the session.
Bug: chromium:1138888
Change-Id: I12d10715fd5ec29f6ee78296ddfe975d7edab8a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208581
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33330}
Trying to take my first stab at contributing to WebRTC and I chose to populate jitter stats for video RTP streams. Please yell at me if this isn't something I'm not supposed to pick up. Appreciate a review, thanks!
Bug: webrtc:12487
Change-Id: Ifda985e9e20b1d87e4a7268f34ef2e45b1cbefa3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208360
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33325}
SystemTimeNanos() will soon be replaced with another implementation
when built with Chromium. This will break the assumption of
SystemTimeNanos() being relative to the NTP epoch. To avoid breaking
any UWP apps, call the TimeHelper::Ticks() function directly, which
is synchronized with the NTP epoch during initialization.
Bug: chromium:516700
Change-Id: I4e50cb3f88d06e1385e73b1a9ded52956501dc1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208520
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33324}
