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}
Registers transport on construction removing the need for ViESender as a
hop and removing a potential deadlock by removing RegisterSendTransport.
BUG=1695, 2999
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/57449004
Cr-Commit-Position: refs/heads/master@{#9309}
The roll seems to cause leaks on our Linux Memcheck bot.
Added a suppression needed for Trusty in order to run
memcheck similar to the bot (that runs Precise).
Leave all the other source code edits from r8596 in place.
See also http://chromegw/i/client.webrtc/builders/Linux%20Memcheck/builds/3343TBR=pbos@webrtc.org
TESTED=Can no longer repro memcheck failure with this patch applied:
GYP_DEFINES="build_for_tool=memcheck" webrtc/build/gyp_webrtc
ninja -C out/Release libjingle_peerconnection_unittest
tools/valgrind-webrtc/webrtc_tests.sh --test libjingle_peerconnection_unittest --tool memcheck --target Release --build-dir out --gtest_filter=WebRtcSessionTest.TestIncorrectMLinesInLocalAnswer
Review URL: https://webrtc-codereview.appspot.com/47419004
Cr-Commit-Position: refs/heads/master@{#8612}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8612 4adac7df-926f-26a2-2b94-8c16560cd09d
Without this patch, Valgrind's Memcheck was complaining that the test
for whether we should return -1 following the call to
WebRtcIsac_DecodeLb made a conditional branch or move based on the
value of numSamplesLB, which was uninitialized if WebRtcIsac_DecodeLb
failed.
However, as can be seen in the source, the control flow only depends
on the value of numSamplesLB if numDecodedBytesLB >= 0; i.e., if
WebRtcIsac_DecodeLb returned successfully, in which case numSamplesLB
is always initialized. The discrepancy is due to the fact that
Valgrind works on the generated machine code, which contains spurious
such dependencies. The generated code for this test:
if ((numDecodedBytesLB < 0) || (numDecodedBytesLB > lenEncodedLBBytes) ||
(numSamplesLB > MAX_FRAMESAMPLES)) {
looks like this:
95: 0f bf 45 d6 movswl -0x2a(%rbp),%eax
99: 3d c0 03 00 00 cmp $0x3c0,%eax
9e: 0f 8f 45 01 00 00 jg 1e9 <Decode+0x1e9>
a4: 44 89 f0 mov %r14d,%eax
a7: c1 e0 10 shl $0x10,%eax
aa: 0f 88 39 01 00 00 js 1e9 <Decode+0x1e9>
b0: 41 0f bf ce movswl %r14w,%ecx
b4: 89 8d 98 e1 ff ff mov %ecx,-0x1e68(%rbp)
ba: 41 0f bf c7 movswl %r15w,%eax
be: 39 c1 cmp %eax,%ecx
c0: 0f 8f 23 01 00 00 jg 1e9 <Decode+0x1e9>
Note how the compiler has seemingly ignored the C language's guarantee
that the arguments to || must be evaluated in left-to-right order, and
compares numSamplesLB (%eax) with MAX_FRAMESAMPLES (0x3c0, a.k.a. 960)
before the other two conditions! If the uninitialized value in
numSamplesLB happens to be greater than 960, we'll jump to
Decode+0x1e9 (where we'll return -1) without even looking at the other
two conditions. Has the compiler generated broken code?
Well, no. If numDecodedBytesLB is < 0 so that numSamplesLB is
uninitialized, we'll end up jumping to 1e9 whether that value is
greater than 960 or not; we'll just do it with different jump
instructions. This is entirely invisible as far as the C language is
concerned, but the dependency on the uninitialized value is visible at
the machine code level, which is why Memcheck complains.
This patch solves the problem by pragmatically initializing
numSamplesLB before the call even though it isn't necessary other than
for placating Memcheck.
BUG=4143
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36309004
Cr-Commit-Position: refs/heads/master@{#8492}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8492 4adac7df-926f-26a2-2b94-8c16560cd09d
New errors arrived when rolling libjingle in r5502.
These suppressions are needed to green up the Memcheck and
TSan bots.
BUG=1976,2080
TEST=local runs on Linux:
tools/valgrind-webrtc/webrtc_tests.sh --tool=tsan -b out/Release -t libjingle_unittest
tools/valgrind-webrtc/webrtc_tests.sh --tool=memcheck -b out/Release -t libjingle_unittest
and trybot:
git try --bot=linux_memcheck,linux_tsan -t libjingle_unittest
TBR=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5509 4adac7df-926f-26a2-2b94-8c16560cd09d
A new test target named 'modules_integrationtests' is created
and the following test targets were merged into it:
* audio_coding_module_test
* test_fec
* video_coding_integrationtests
* vp8_integrationtests
A couple of other targets were merged into modules_unittests:
* audio_coding_unittests
* audioproc_unittest
* common_unittests
* video_coding_unittests
* video_processing_unittests
* vp8_unittests
I wasn't able to merge audio_decoder_unittests and neteq_unittests due to
conflicts with different defines in these tests.
Some tests that have special requirements aren't merged into
modules_integrationtests yet. I took the opportunity to rename them
since the bot configs will need to be update anyway:
* audio_device_test_api -> audio_device_integrationtests
* video_capture_module_test -> video_capture_integrationtests
* video_render_module_test -> video_render_integrationtests
Exclude files were added for modules_integrationtests to make sure
the memcheck and tsan bots doesn't tests that are too slow
(audio_coding_module_test and vp8_integrationtests were previously
disabled on those bots).
Suppressions for AudioCodingModuleTest needed to be added to get
modules_integrationtests to pass memcheck (even if the test is
excluded from execution).
BUG=1843
TEST=local execution on Linux and trybots (passing except the merged tests of course)
R=andrew@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1656004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4228 4adac7df-926f-26a2-2b94-8c16560cd09d
Turns out the bot is running a different version of libpthread, probably because I'm on gPrecise / gcc 4.6 whereas the bot is on 4.4? Anyway, I've generalized that stuff now.
BUG=
TEST=Ran voe & vie_auto_test under valgrind locally.
Review URL: https://webrtc-codereview.appspot.com/908004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@2973 4adac7df-926f-26a2-2b94-8c16560cd09d
Also Suppressed FakeMediaProcess errors (bug 898) and took out a test and suppressed general errors (bug 332). Lastly, fixed memory leak in misc test.
BUG=898, 332
TEST=Ran voe_auto_test with repeat=10 through the whole standard suite, under valgrind. Ran without valgrind. Tested that the extended and standard tests still start and are reachable from the menu.
Review URL: https://webrtc-codereview.appspot.com/855009
git-svn-id: http://webrtc.googlecode.com/svn/trunk@2898 4adac7df-926f-26a2-2b94-8c16560cd09d
