Was causing warnings in Chromium such as:
warning C4742: 'WebRtcAec_overDriveCurve' has different alignment in 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core_sse2.c' and 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core.c': 4 and 16
warning C4744: 'WebRtcAec_overDriveCurve' has different type in 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core_sse2.c' and 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core.c': 'array (260 bytes)' and '__declspec(align(16)) array (260 bytes)'
warning C4742: 'WebRtcAec_weightCurve' has different alignment in 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core_sse2.c' and 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core.c': 4 and 16
warning C4744: 'WebRtcAec_weightCurve' has different type in 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core_sse2.c' and 'E:\src\buildbot\build\slave\fake_slave\build\src\third_party\webrtc\modules\audio_processing\aec\aec_core.c': 'array (260 bytes)' and '__declspec(align(16)) array (260 bytes)'
BUG=https://code.google.com/p/chromium/issues/detail?id=336620R=andrew@webrtc.org, cd@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15869004
Patch from Sebastien Marchand <sebmarchand@chromium.org>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6525 4adac7df-926f-26a2-2b94-8c16560cd09d
This should work as a foundation for all the work that is
left to do to make the parts of WebRTC that Chromium uses
to build with GN.
I implemented some the smaller modules myself in this CL.
The remaining work (TODO's in the .gn files) will be distributed
to various team members.
I'm adding myself to OWNERS files for BUILD.gn files in all the
directories where I'm adding a BUILD.gn file.
BUG=3441
TEST=
Successful compilation of WebRTC as standalone:
gn gen out/Default --args="build_with_chromium=false" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false is_clang=true clang_use_chrome_plugins=false" && ninja -C out/Default
I built successfully from a Chromium checkout (with
https://codereview.chromium.org/321313006/ applied) using:
gn gen out/Default && ninja -C out/Default webrtc
R=brettw@chromium.org, niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/13749004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6523 4adac7df-926f-26a2-2b94-8c16560cd09d
After rolling chromium_revision in r6516 it seems
TSan v2 turned on deadlock detection by default.
This caused a collection of tests to start failing.
This CL suppresses these failures awaiting further
investigation.
TBR=pbos@webrtc.org
BUG=3509
TEST=Tests passing local execution on Linux using the
reproduction steps in the bug.
Review URL: https://webrtc-codereview.appspot.com/18609004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6519 4adac7df-926f-26a2-2b94-8c16560cd09d
The PeerConnectionEndToEndTest.DataChannelIdAssignment test fails
flakily like this:
[----------] 1 test from PeerConnectionEndToEndTest
[ RUN ] PeerConnectionEndToEndTest.DataChannelIdAssignment
WARNING: no real random source present!
../../talk/app/webrtc/test/peerconnectiontestwrapper.cc:216: Failure
Value of: CheckForConnection()
Actual: false
Expected: true
[ FAILED ] PeerConnectionEndToEndTest.DataChannelIdAssignment (13215 ms)
[----------] 1 test from PeerConnectionEndToEndTest (13223 ms total)
TBR=wu@webrtc.org
BUG=
Review URL: https://webrtc-codereview.appspot.com/20759004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6518 4adac7df-926f-26a2-2b94-8c16560cd09d
Rolling to this new Chromium revision required us to introduce
a sanitizer_options similar to the one in Chromium's base
(see https://code.google.com/p/chromium/codesearch#chromium/src/base/base.gyp&l=977
and https://codereview.chromium.org/238123003) in order
to get the same defaults for ASan and LSan. Without it
compilation will break since LeakSanitizer (LSan) is enabled by
default in Clang r209387 that is pulled with this roll.
I setup so that we pull in the sanitizer_options.cc and
tsan_suppressions.cc files using DEPS, so we don't have to maintain
them separately for now. We can still use our own TSan suppressions.txt
file as we do today with no changes needed.
This roll also brings in http://crrev.com/276676 so we can enable
GN build for WebRTC.
Overview of changes in Chrome DEPS:
$ svn diff http://src.chromium.org/chrome/trunk/src/DEPS -r 272489:277350
which can be compared with the output of:
$ svn cat http://webrtc.googlecode.com/svn/trunk/DEPS | grep chromium_deps | sed 's/^ *//' | sort | uniq
in a WebRTC checkout, gives the following relevant changes:
* third_party/android_tools 6fc0e1:c6e658
* third_party/libjpeg_turbo 263594:272637
* third_party/libyuv 1000:1007
* third_party/nss 271760:277057
* tools/gyp 1921:1927
* tools/swarming_client ae8085:aea506
The following also shows that Clang is upgraded from r206824 to r209387:
$ svn diff http://src.chromium.org/chrome/trunk/src/tools/clang/scripts/update.sh -r 272489:277350
BUG=3441
TEST=Trybots are not passing since after the recipe switch, SVN-based try jobs doesn't seem to support auto-detecting that a sync is needed if there's a DEPS change.
R=andrew@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12729004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6516 4adac7df-926f-26a2-2b94-8c16560cd09d
This change is based on RFC3264:
"Although the answerer MAY list the formats in their desired order of preference, it is RECOMMENDED that unless there is a specific reason, the answerer list formats in the same relative order they were present in the offer."
BUG=2868
TEST=unit tests and manually with munge-sdp test
R=juberti@google.com
Review URL: https://webrtc-codereview.appspot.com/14589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6514 4adac7df-926f-26a2-2b94-8c16560cd09d
- Allocate real texture for camera preview.
- Add fps and camera frame duration logging.
- Get camera frame timestamp in Java code and pass it to jni code so the frame timestamp is assigned as soon as possible. Jni code will not use these timestamps yet until timestamp ntp correction and zeroing in webrtcvideengine.cc will be addressed.
R=fischman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16729004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6513 4adac7df-926f-26a2-2b94-8c16560cd09d
To save memory in iSAC-fix, decoder operated directly on the recieved bitstream. However, this breaks constantness of input when decoder performed in-place big to little Endian conversion. Furthermore, for bit-streams with odd lengths, this meant writing outside the memory. That is because the last byte will be shifted to the Most Significat Byte which might be outside the allocated memory.
If we care about memory, the solution is to do a big-to-little Endian conversion everytime we read a Word16 from the bitstream.
BUG=845,chrome:379458
R=henrik.lundin@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15829004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6494 4adac7df-926f-26a2-2b94-8c16560cd09d
- Disables ApmTest.EchoCancellationReportsCorrectDelays
This test relys completely on the structure of how reported system delays are handled in AEC. In addition it assumes a fix setup of delay logging buffers. This test should be refactored.
- Adds flag to turn off reported_delay in audioproc
Now it is feasible to turn on and off the use of reported system delays.
BUG=N/A
R=aluebs@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16749004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6492 4adac7df-926f-26a2-2b94-8c16560cd09d
The AudioSink interface is supposed to be used by tests that produce
audio output. Two implementation classes are also provided:
OutputAudioFile: Writes the audio to a pcm file.
AudioChecksum: Calculates the MD5 checksum of the audio.
These will both be used in future changes.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/17729004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6490 4adac7df-926f-26a2-2b94-8c16560cd09d
Several tests were disabled in r6325 and r6326. Also, see issue 3445. This CL fixes the remaining four of the audio_processing related ones. Affects the tests:
- SystemDelayTest.CorrectDelayAfterStableBufferBuildUp
- SystemDelayTest.CorrectDelayDuringDrift
- SystemDelayTest.ShouldRecoverAfterGlitch
- ApmTest.EchoCancellationReportsCorrectDelays
The tests assumes reported delays are used, which now is explicitly set.
BUG=3445
TESTED=trybots
R=aluebs@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19769004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6489 4adac7df-926f-26a2-2b94-8c16560cd09d
The NextPacket method should now return NULL when the end of the
source was reached. In the RtpFileSource, this means that when
the end of file is reached, NULL is returned. Also, when an RTCP
packet is encountered, the next packet will be read from file
immediately.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20699004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6479 4adac7df-926f-26a2-2b94-8c16560cd09d
