The check: 'RTC_CHECK_GE(slice_height, height);' has been observed to
fail after a reconfig. It looks like |slice_height| is still using the
previous resolution. |slice_height| isn't used for texture output and
hopefully this issue is texture specific. This CL only extracts and
checks |slice_height| when it's actually used.
BUG=b/35932686
Review-Url: https://codereview.webrtc.org/2736603003
Cr-Commit-Position: refs/heads/master@{#17065}
This will allow the trybots to be updated to start running this new test
executable, so that they can be used when landing this CL which will
replace the dummy test with real code:
https://codereview.webrtc.org/2694203002
Most likely, the trybots will just run the test binary while the perf bots
will run a Python wrapper script that takes care of the post-processing
to calculate audio quality using PESQ.
BUG=webrtc:7229
NOTRY=True
Review-Url: https://codereview.webrtc.org/2717683002
Cr-Commit-Position: refs/heads/master@{#17063}
Reason for revert:
The issue is now hopefully fixed.
Original issue's description:
> Revert of Add QP for FFmpeg H264 decoder. (patchset #4 id:200001 of https://codereview.webrtc.org/2649133007/ )
>
> 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: 879f4f6c31
>
> TBR=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}
> Committed: 4c6df8893eTBR=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/2735733002
Cr-Commit-Position: refs/heads/master@{#17061}
We currently don't know how to parse these NALus and we don't need
any information from them anyway so we might as well skip parsing them
and not break.
BUG=chromium:697795
Review-Url: https://codereview.webrtc.org/2732623002
Cr-Commit-Position: refs/heads/master@{#17057}
This CL is a reland of https://codereview.webrtc.org/2722423003 which got
reverted due to compile errors when rolling into Chromium.
Original CL description:
Improve testing of SRTP external auth code paths.
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/2735613002
Cr-Commit-Position: refs/heads/master@{#17052}
After profiling, sakal@ found that this method was taking very long,
and causing the bitstream parsing to take up to 1ms per frame. The
culprit proved to be rtc::Buffer::AppendData, which was called for
every byte and subsequently calls memcpy.
BUG=webrtc:7293
Review-Url: https://codereview.webrtc.org/2728093002
Cr-Commit-Position: refs/heads/master@{#17051}
Introduce new target //webrtc/p2p:rtc_p2p_test_utils to host
test-related utilities.
Previously uncovered header "base/fakecandidatepair.h" is now also in a target.
BUG=webrtc:6828
Review-Url: https://codereview.webrtc.org/2714263004
Cr-Commit-Position: refs/heads/master@{#17036}
Reason for revert:
Breaks compilation in FYI bots, e.g. here:
http://build.chromium.org/p/chromium.webrtc.fyi/builders/Win%20Builder/builds/9314
FAILED: obj/third_party/webrtc/pc/rtc_pc/channel.obj
ninja -t msvc -e environment.x86 -- E:\b\c\goma_client/gomacc.exe "E:\b\depot_tools\win_toolchain\vs_files\d3cb0e37bdd120ad0ac4650b674b09e81be45616\VC\bin\amd64_x86/cl.exe" /nologo /showIncludes /FC @obj/third_party/webrtc/pc/rtc_pc/channel.obj.rsp /c ../../third_party/webrtc/pc/channel.cc /Foobj/third_party/webrtc/pc/rtc_pc/channel.obj /Fd"obj/third_party/webrtc/pc/rtc_pc_cc.pdb"
e:\b\c\b\win_builder\src\third_party\webrtc\pc\channel.cc(176): error C2819: type 'cricket::SrtpFilter' does not have an overloaded member 'operator ->'
e:\b\c\b\win_builder\src\third_party\webrtc\pc\srtpfilter.h(45): note: see declaration of 'cricket::SrtpFilter'
e:\b\c\b\win_builder\src\third_party\webrtc\pc\channel.cc(176): note: did you intend to use '.' instead?
e:\b\c\b\win_builder\src\third_party\webrtc\pc\channel.cc(176): error C2232: '->cricket::SrtpFilter::EnableExternalAuth': left operand has 'class' type, use '.'
Original issue's description:
> Improve testing of SRTP external auth code paths.
>
> 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}
> Committed: ac170d5c21TBR=deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:628400
Review-Url: https://codereview.webrtc.org/2734643002
Cr-Commit-Position: refs/heads/master@{#17031}
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}
