Previously code behind ENABLE_EXTERNAL_AUTH was only compiled with Chromium
but developed in WebRTC, which made testing rather complicated. This caused
some trouble in the past (e.g. https://crbug.com/628400#c1)
This CL helps in that the external auth code is now compiled with WebRTC
and the srtpfilter integration gets tested.
BUG=chromium:628400
Review-Url: https://codereview.webrtc.org/2722423003
Cr-Commit-Position: refs/heads/master@{#17030}
Reason for revert:
Trying to fix this skipping the check if we are building webrtc within chromium.
Original issue's description:
> Revert of Setting is_component_build to false by default (patchset #5 id:80001 of https://codereview.webrtc.org/2728643003/ )
>
> Reason for revert:
> Breaks chrome rolls
>
> Original issue's description:
> > Setting is_component_build to false by default
> >
> > Webrtc does not support component builds so we want to override
> > the chromium default value (which can be true on debug builds if the
> > os is different from iOS).
> >
> > Please note that the user can set this value to true in two ways:
> >
> > - using --args (e.g.: gn gen out/default --args='is_component_build=true'
> > - changing the value in the args.gn file
> >
> > But in both cases the value will be ignored because we don't use the
> > 'component' template but we rely directly on 'rtc_static_library' and
> > 'rtc_shared_library'.
> >
> > BUG=webrtc:6975
> > NOTRY=True
> >
> > Review-Url: https://codereview.webrtc.org/2728643003
> > Cr-Commit-Position: refs/heads/master@{#17020}
> > Committed: 2cb3944ba7
>
> TBR=kjellander@webrtc.org,mbonadei@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6975
>
> Review-Url: https://codereview.webrtc.org/2731703004
> Cr-Commit-Position: refs/heads/master@{#17025}
> Committed: 2d9e7685a5TBR=kjellander@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6975
Review-Url: https://codereview.webrtc.org/2729243003
Cr-Commit-Position: refs/heads/master@{#17027}
Reason for revert:
Breaks chrome rolls
Original issue's description:
> Setting is_component_build to false by default
>
> Webrtc does not support component builds so we want to override
> the chromium default value (which can be true on debug builds if the
> os is different from iOS).
>
> Please note that the user can set this value to true in two ways:
>
> - using --args (e.g.: gn gen out/default --args='is_component_build=true'
> - changing the value in the args.gn file
>
> But in both cases the value will be ignored because we don't use the
> 'component' template but we rely directly on 'rtc_static_library' and
> 'rtc_shared_library'.
>
> BUG=webrtc:6975
> NOTRY=True
>
> Review-Url: https://codereview.webrtc.org/2728643003
> Cr-Commit-Position: refs/heads/master@{#17020}
> Committed: 2cb3944ba7TBR=kjellander@webrtc.org,mbonadei@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6975
Review-Url: https://codereview.webrtc.org/2731703004
Cr-Commit-Position: refs/heads/master@{#17025}
DXGI capturer highly depends on video adapter and its driver, as well as Windows
itself. I recently found it cannot work on my virtualbox instance any more,
which indicates it may not work well on some specific systems. What worse is,
the APIs do not return a failure in such case.
So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
pixels in the frame returned by a DesktopCapturer implementation. If all the
pixels selected are blank, this wrapper returns a failure. A typical usage is to
combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
and use GDI capturer in case of failure.
Usually less than 10000 pixels are checked, so the
BlankDetectorDesktopCapturerWrapper should not significant impact the capturer
performance.
This change is expected to resolve bug 682112 in another dimension.
BUG=682112
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Original-Commit-Position: refs/heads/master@{#16984}
Committed: c4e9d210b3
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Commit-Position: refs/heads/master@{#17024}
Create the SrtpTransportInterface, a subclass of RtpTransportInterface, which
allows the user to set the send and receive keys. The functionalities are
implemented inside the RtpTransportAdapters on top of BaseChannel.
BUG=webrtc:7013
Review-Url: https://codereview.webrtc.org/2714813004
Cr-Commit-Position: refs/heads/master@{#17023}
Webrtc does not support component builds so we want to override
the chromium default value (which can be true on debug builds if the
os is different from iOS).
Please note that the user can set this value to true in two ways:
- using --args (e.g.: gn gen out/default --args='is_component_build=true'
- changing the value in the args.gn file
But in both cases the value will be ignored because we don't use the
'component' template but we rely directly on 'rtc_static_library' and
'rtc_shared_library'.
BUG=webrtc:6975
NOTRY=True
Review-Url: https://codereview.webrtc.org/2728643003
Cr-Commit-Position: refs/heads/master@{#17020}
1. Packet reception statistics (PLR and RPLR) calculated on each stream separately.
2. Algorithm changed from considering separate quadrants of the sequence-number-ring to simply looking at the oldest in-window SENT packet.
BUG=webrtc:7058
Review-Url: https://codereview.webrtc.org/2632203002
Cr-Commit-Position: refs/heads/master@{#17018}
Pointer was already protected by a critical section in two places but
not the third. Added thread annotations to prevent this from happening
in the future.
BUG=None
Review-Url: https://codereview.webrtc.org/2726263004
Cr-Commit-Position: refs/heads/master@{#17017}
This isn't used any more so there's no point in maintaining it.
BUG=None
Review-Url: https://codereview.webrtc.org/2731673002
Cr-Commit-Position: refs/heads/master@{#17016}
To properly test the functionality, following changes were needed
- Make RTCMTLVideoView compiliable for all cpu architectures not just arm64.
This is needed so that the test can run on any device and on simulator as well.
- Refactor RTCMTLVideoView to have mockable class methods.
The unittest class, RTCMTLVideoViewTests was designed to provide easy transition
to XCTest when the time comes for that.
To transition to XCTest it would suffice to inherit from XCTestCase and remove
the gtest methods.
BUG=webrtc:7079
Review-Url: https://codereview.webrtc.org/2723903003
Cr-Commit-Position: refs/heads/master@{#17014}
It generates json files to be used as APM configuration presets.
Useful to avoid manual editing of such files.
BUG=webrtc:7218
NOTRY=True
Review-Url: https://codereview.webrtc.org/2719853006
Cr-Commit-Position: refs/heads/master@{#17013}
New Opus version starts to support 120ms frame lengths. AudioEncoderOpusTest had an unnecessary check on the available frame lengths.
It is removed in this CL.
BUG=b/35415318
Review-Url: https://codereview.webrtc.org/2731583003
Cr-Commit-Position: refs/heads/master@{#17011}
Execution flag added to the .py and .sh scripts.
BUILD.gn files adapted (see :lib), APM config files moved.
BUG=webrtc:7218
NOTRY=True
Review-Url: https://codereview.webrtc.org/2715943002
Cr-Commit-Position: refs/heads/master@{#17007}
In short, what I did was to
* Remove acm_common_defs.h (the stuff in it was used only by
acm_codec_database.cc).
* Move audio_coding_module_typedefs.h to a new build target.
* Move the NetEqDecoder enum (and the associated
NetEqDecoderToSdpAudioFormat function) to a new file in a new
build target.
BUG=webrtc:7243, webrtc:7244
Review-Url: https://codereview.webrtc.org/2723253005
Cr-Commit-Position: refs/heads/master@{#17005}
- The RTC_SUPPORTS_METAL macro allows consumers to gracefully handle compilation for different archs that are not supporting Metal.
BUG=webrtc:7079
Review-Url: https://codereview.webrtc.org/2722583002
Cr-Commit-Position: refs/heads/master@{#17004}
A fuzzer run caused the operands of this multiplication to be 512 and
5000000, resulting in a product about 20% too large for int32_t. So
change this from a 16x32->32 to a 16x32->64 multiplication. Since we
right shift by 2 at the end, the end result will still fit in int32_t.
I also had to fix a few follow-on add/sub overflows found by the same
fuzzer input once the multiplication was fixed. I chose to saturate
these, since it wasn't just an intermediate value that overflowed.
BUG=chromium:693868
Review-Url: https://codereview.webrtc.org/2729573002
Cr-Commit-Position: refs/heads/master@{#17003}
Hopefully this will reduce the flakiness of PostDelayedTask.
BUG=none
Review-Url: https://codereview.webrtc.org/2728663008
Cr-Commit-Position: refs/heads/master@{#17001}
Add extra checks to it to simplify diagnostic should it fail again.
BUG=webrtc:7292
Review-Url: https://codereview.webrtc.org/2728103002
Cr-Commit-Position: refs/heads/master@{#16999}
This makes a few things a lot clearer when looking at perf trace data:
* What module instances (where they were created) are called
* On what thread
* How frequently
* For how long
ProcessThread will be replaced by TaskQueue moving forward and this is a step towards understanding the behavior of the affected code.
BUG=webrtc:7219
Review-Url: https://codereview.webrtc.org/2729053002
Cr-Commit-Position: refs/heads/master@{#16998}
This CL fixes two issues. The first is a tsan complaint about a data
race. The test had a fix to make it deterministic but the race still
existed, so this adds locks around the critical section to appease
the sanitizer.
The second, more annoying issue, is that occasionally the test would
start before the encoder had been configured, as this happens
asynchronously on a task queue. This would cause frames to be queued
up and dropped, but not where we expected them to be dropped.
This was causing some tests to fail very occasionally. I've added
a synchronisation mechanism by posting a barrier task on the queue
and not proceeding with the tests until it finishes.
BUG=webrtc:7217, webrtc:7232, webrtc:7260
Review-Url: https://codereview.webrtc.org/2722183004
Cr-Commit-Position: refs/heads/master@{#16995}
Reason for revert:
Misses deps for RTC_HISTOGRAM in Chrome.
email sent separately.
Also see https://codereview.chromium.org/2725143004/.
Original issue's description:
> BlankDetectorDesktopCapturerWrapper to detect a blank DesktopFrame
>
> DXGI capturer highly depends on video adapter and its driver, as well as Windows
> itself. I recently found it cannot work on my virtualbox instance any more,
> which indicates it may not work well on some specific systems. What worse is,
> the APIs do not return a failure in such case.
>
> So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
> pixels in the frame returned by a DesktopCapturer implementation. If all the
> pixels selected are blank, this wrapper returns a failure. A typical usage is to
> combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
> and use GDI capturer in case of failure.
>
> Usually less than 500 pixels are checked, so the
> BlankDetectorDesktopCapturerWrapper should not impact the capturer performance.
>
> This change is expected to resolve bug 682112 in another dimension.
>
> BUG=682112
>
> Review-Url: https://codereview.webrtc.org/2709523003
> Cr-Commit-Position: refs/heads/master@{#16984}
> Committed: c4e9d210b3TBR=sergeyu@chromium.org,zijiehe@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=682112
Review-Url: https://codereview.webrtc.org/2726983005
Cr-Commit-Position: refs/heads/master@{#16993}
Reason for revert:
I wasn't able to resolve it with that CL so I'll have to revert this by now.
Will have another look at this when time permits.
Original issue's description:
> Enable GN check for webrtc/examples
>
> BUG=webrtc:6828
> NOTRY=True
>
> Review-Url: https://codereview.webrtc.org/2714343002
> Cr-Commit-Position: refs/heads/master@{#16987}
> Committed: 81db74a384TBR=perkj@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6828
Review-Url: https://codereview.webrtc.org/2727253003
Cr-Commit-Position: refs/heads/master@{#16991}
Reason for revert:
Fails Chromium builds:
b/c/b/linux/src/buildtools/linux64/gn gen //out/Release --check
-> returned 1
ERROR at //third_party/webrtc/api/BUILD.gn:186:5: Can't load input file.
"//webrtc/test:test_support",
^-------------------------
Original issue's description:
> GN: Include webrtc/api targets even if rtc_include_tests=false
>
> The main purpose with the rtc_include_tests GN variable is to avoid
> generating and compiling all the test targets.
> Some of our examples have dependencies on the test headers in API,
> so therefore this change is relaxing that condition.
>
> BUG=webrtc:6828
> NOTRY=True
> TBR=ehmaldonado@webrtc.org,
>
> Review-Url: https://codereview.webrtc.org/2725053008
> Cr-Commit-Position: refs/heads/master@{#16989}
> Committed: a769ceba65TBR=ehmaldonado@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6828
Review-Url: https://codereview.webrtc.org/2728073002
Cr-Commit-Position: refs/heads/master@{#16990}
The main purpose with the rtc_include_tests GN variable is to avoid
generating and compiling all the test targets.
Some of our examples have dependencies on the test headers in API,
so therefore this change is relaxing that condition.
BUG=webrtc:6828
NOTRY=True
TBR=ehmaldonado@webrtc.org,
Review-Url: https://codereview.webrtc.org/2725053008
Cr-Commit-Position: refs/heads/master@{#16989}
DXGI capturer highly depends on video adapter and its driver, as well as Windows
itself. I recently found it cannot work on my virtualbox instance any more,
which indicates it may not work well on some specific systems. What worse is,
the APIs do not return a failure in such case.
So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
pixels in the frame returned by a DesktopCapturer implementation. If all the
pixels selected are blank, this wrapper returns a failure. A typical usage is to
combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
and use GDI capturer in case of failure.
Usually less than 500 pixels are checked, so the
BlankDetectorDesktopCapturerWrapper should not impact the capturer performance.
This change is expected to resolve bug 682112 in another dimension.
BUG=682112
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Commit-Position: refs/heads/master@{#16984}
It seems to me that we're currently just picking the first CN codec, rather than the one that matches the clock rate of the voice codec. The only test I've gotten to fail by changing this behavior is the one that's also changed in this CL, which explicitly expects a CN codec to be chosen even though there's none matching.
BUG=webrtc:7282
Review-Url: https://codereview.webrtc.org/2707133007
Cr-Commit-Position: refs/heads/master@{#16979}
Callback used to be reported periodically (each 1000ms) but is now reported per frame.
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2729903002
Cr-Commit-Position: refs/heads/master@{#16977}
Reason for revert:
Let's revert this while we investigate a problem in H264 bitstream parser.
Original issue's description:
> Add QP for FFmpeg H264 decoder.
>
> BUG=webrtc:6541
>
> Review-Url: https://codereview.webrtc.org/2649133007
> Cr-Commit-Position: refs/heads/master@{#16942}
> Committed: 879f4f6c31TBR=sprang@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6541, chromium:697795
Review-Url: https://codereview.webrtc.org/2726973003
Cr-Commit-Position: refs/heads/master@{#16974}
This adds a simple mechanism that provides protection against
implementations that use the legacy callback type in PlatformThread
and are prone to entering a busy loop.
Enabled only in DCHECK enabled builds.
BUG=webrtc:7187
Review-Url: https://codereview.webrtc.org/2720223003
Cr-Commit-Position: refs/heads/master@{#16973}
Reason for revert:
Investigation complete.
Original issue's description:
> H264BitstreamParser: Log nalu type when parsing slice type fails.
>
> Decreases all parsing failures to a warning because they are not
> critical errors. This is a speculative commit to help diagnose
> why bots are failing.
>
> BUG=chromium:697795
> TBR=stefan@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2726833005
> Cr-Commit-Position: refs/heads/master@{#16966}
> Committed: 6bce6ad485TBR=stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:697795
Review-Url: https://codereview.webrtc.org/2723883004
Cr-Commit-Position: refs/heads/master@{#16972}
Reason for revert:
Causes regression in VP8 simulcast metrics (receive time, encoded frame size, etc) as two excluded streams' decoders request keyframes periodically, which affects metrics of a selected stream.
Original issue's description:
> In full-stack tests: fixed VP8 simulcast to not decode non-selected streams.
>
> BUG=webrtc:7095
>
> Review-Url: https://codereview.webrtc.org/2728553003
> Cr-Commit-Position: refs/heads/master@{#16948}
> Committed: 8dccd67520TBR=sprang@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7095
Review-Url: https://codereview.webrtc.org/2729623005
Cr-Commit-Position: refs/heads/master@{#16967}
Decreases all parsing failures to a warning because they are not
critical errors. This is a speculative commit to help diagnose
why bots are failing.
BUG=chromium:697795
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2726833005
Cr-Commit-Position: refs/heads/master@{#16966}
