It's at the same level as the other end-to-end tests that are also
disabled. It seems to be failing because it's not fast enough to keep up
with processing fake video frames.
BUG=webrtc:4387
TBR=kjellander@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2538783002
Cr-Commit-Position: refs/heads/master@{#15302}
Add a fallback path to tools/valgrind-webrtc/webrtc_tests.sh if locate_valgrind.sh fails.
This is a workaround to run memcheck on swarming, since locate_valgrind.sh fails even though the files are present. This is almost certainly because the way we use symlinks.
A warning message is displayed to warn the developers to follow the instructions to get the valgrind binaries.
Some extra suppressions were needed. The bug tracking them is https://bugs.webrtc.org/6773R=kjellander@chromium.org
BUG=chromium:497757
Review-Url: https://codereview.webrtc.org/2531573003
Cr-Commit-Position: refs/heads/master@{#15244}
Reason for revert:
Didn't work
Original issue's description:
> Modify the paths of the resource files to point to chromium/src/tools/...
>
> R=kjellander@chromium.org
> BUG=chromium:497757
> NOTRY=True
>
> Committed: https://crrev.com/d8ae20b362f76d2153fa65b5d82d534c546c59a4
> Cr-Commit-Position: refs/heads/master@{#15225}
TBR=kjellander@chromium.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:497757
Review-Url: https://codereview.webrtc.org/2532453002
Cr-Commit-Position: refs/heads/master@{#15226}
When set to true, this adds the files necessary to run memcheck as data dependencies, listed in the .gni files.
This will enable us to run memcheck on swarming.
R=kjellander@chromium.org
BUG=chromium:497757
NOTRY=True
Review-Url: https://codereview.webrtc.org/2510033004
Cr-Commit-Position: refs/heads/master@{#15219}
The Dr Memory toolchain is no longer supported by Chromium and
their bots have been removed. WebRTC will now rely on the LLVM
santizers for catching such errors.
BUG=webrtc:6553
NOTRY=True
R=ehmaldonado@webrtc.org
Review URL: https://codereview.webrtc.org/2434563003 .
Cr-Commit-Position: refs/heads/master@{#14703}
This change is to add more test cases for ScreenCapturer implementation.
BUG=
Review-Url: https://codereview.webrtc.org/2320763003
Cr-Commit-Position: refs/heads/master@{#14218}
NSS has been replaced by BoringSSL/OpenSSL on all platforms, so the memcheck
suppressions should no longer be required.
BUG=
R=kjellander@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2222243002
Cr-Commit-Position: refs/heads/master@{#13686}
The test sent a media packet, then verified it was sent by checking the
"last packet sent"'s ID. But the last packet sent may have been
a STUN packet that came *after* the media packet.
BUG=webrtc:5978
Review-Url: https://codereview.webrtc.org/2071573002
Cr-Commit-Position: refs/heads/master@{#13156}
ViEEncoder doesn't need a full VideoCodingModule since it only uses the
sender side either way.
BUG=webrtc:3608,webrtc:5687
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1904983002 .
Cr-Commit-Position: refs/heads/master@{#12456}
Previous suppressions for libjingle_media_unittest stopped working when
the target was renamed rtc_media_unittests causing the bots to start
flaking.
BUG=
TBR=kjellander@webrtc.org
Review URL: https://codereview.webrtc.org/1698873002 .
Cr-Commit-Position: refs/heads/master@{#11624}
Reason for revert:
Disabling tests on memcheck that time out due to using real VP8 encoders.
Original issue's description:
> Revert of Don't send FEC for H.264 with NACK enabled. (patchset #5 id:80001 of https://codereview.webrtc.org/1687303002/ )
>
> Reason for revert:
> Broke the VerifyHistogramStatsWithRed test on the Windows DrMemory Full bot and Linux Memcheck bot. Please fix the test and reland.
>
> Original issue's description:
> > Don't send FEC for H.264 with NACK enabled.
> >
> > The H.264 does not contain picture IDs and are not sufficient to
> > determine that a packet may be skipped. This causes retransmission
> > requests for FEC that are currently dropped by the sender (since they
> > should be redundant).
> >
> > The receiver is then unable to continue without having the packet gap
> > filled (unlike VP8/VP9 which moves on since it has a consecutive stream
> > of picture IDs).
> >
> > Even if FEC retransmission did work it's a huge waste of bandwidth,
> > since it just adds additional overhead that has to be unconditionally
> > transmitted. This bandwidth is better used to send higher-quality
> > frames.
> >
> > BUG=webrtc:5264
> > R=stefan@webrtc.org
> >
> > Committed: https://crrev.com/25558ad819b4df41ba51537e26a77480ace1e525
> > Cr-Commit-Position: refs/heads/master@{#11601}
>
> TBR=stefan@webrtc.org,pbos@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5264
>
> Committed: https://crrev.com/29ffdc1a15e31bd81e806ff135c2100d811714f0
> Cr-Commit-Position: refs/heads/master@{#11607}
TBR=stefan@webrtc.org,deadbeef@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5264
Review URL: https://codereview.webrtc.org/1697093002 .
Cr-Commit-Position: refs/heads/master@{#11621}
This reverts commit 1a8240c32a14a31b1417b6e06f511f2a16d81b19.
Per comments in bug 5136, the affected test should no longer be flaky.
BUG=webrtc:5136
Review URL: https://codereview.webrtc.org/1616273004
Cr-Commit-Position: refs/heads/master@{#11360}
