Adds a SCRIPT_VERSION and the target_os_list to the flag file content. The
script version is so that we can arbitrarially make all slaves/devs re-sync (in
case we change the implementation but don't want to roll chromium), and the
target_os_list is so that devs who change the target_os_list in their .gclient
file don't mysteriously fail to get the new deps.
R=kjellander@webrtc.org, agable@chromium.org, szager@chromium.org
BUG=2863, chromium:339647
Review URL: https://webrtc-codereview.appspot.com/17189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6952 4adac7df-926f-26a2-2b94-8c16560cd09d
This test verifies bit exactness for the send-side of ACM. The test
setup is a chain of three different test classes:
test::AcmSendTest -> AcmSenderBitExactness -> test::AcmReceiveTest
The receiver side is driving the test by requesting new packets from
AcmSenderBitExactness::NextPacket(). This method, in turn, asks for the
packet from test::AcmSendTest::NextPacket, which inserts audio from the
input file until one packet is produced. (The input file loops
indefinitely.) Before passing the packet to the receiver, the
AcmSenderBitExactness class verifies the packet header and updates a
payload checksum with the new payload. The decoded output from the
receiver is also verified with a (separate) checksum.
The current CL only adds tests for 30 ms and 60 ms iSAC. More codecs
will be added in coming changes.
BUG=3521
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20179004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6949 4adac7df-926f-26a2-2b94-8c16560cd09d
This test has been failing every now and then. This is likely due to the
random input that was used. With this change, the input is now read from
an audio file, making it identical on each run.
The encoding is moved to inside the main test loop, so that new data is
added with each packet. (Before this change, the same payload was added
over and over again; only the RTP header was updated.)
BUG=3715
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19079004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6948 4adac7df-926f-26a2-2b94-8c16560cd09d
An unsigned int was passed through %lu instead of %u (harmless on 32bit).
More seriously, a wide string was passed through %s, which means only the
first byte in the string got printed (since the 2nd byte is likely 0 in
UCS-2). Use %ls to include the whole string, even though it might not be
renderable in the target 8bit buffer.
BUG=chromium:82385
R=henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22409004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6946 4adac7df-926f-26a2-2b94-8c16560cd09d
In r6939 the --verbose flag was passed to the problematic
(approx 2.2GB large) gclient sync of Chromium's src.git repo.
However the bots are still hitting killed sync jobs due to
lack of output. This is a speculative attempt to provoke
even more logging, in order to trigger buffer flushing for
the buildbot execution.
BUG=2863, chromium:339647
TEST=Ran gclient runhooks locally with CHROME_HEADLESS=1 set.
TBR=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/21269004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6940 4adac7df-926f-26a2-2b94-8c16560cd09d
In r6938 the switch to using Chromium's Git repo was
deployed. However this fails on the bots since their timeout
for steps without output is 1200 seconds, which is not enough
to checkout the large Chromium Git repo.
Adding --verbose will print more output, thus getting a longer
timeout that should be enough for the runhooks step to complete.
BUG=2863, chromium:339647
TEST=None
TBR=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15209004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6939 4adac7df-926f-26a2-2b94-8c16560cd09d
WebRTC standalone shares a lot of dependencies and build
tools with Chromium. To make the build work, many of the
paths of a Chromium checkout is now emulated by creating
symlinks to files and directories.
All DEPS entries that previously used Var("chromium_trunk")
to reference a Chromium checkout or From("chromium_deps"..)
to reference the Chromium DEPS file are now removed and
replaced by symlink entries in setup_links.py.
The script also handles cleanup of the legacy
Subversion-based dependencies that's needed for the
transition.
Windows: One Windows-specific important change is that
gclient sync|runhooks must now be run from a shell
with Administrator privileges in order to be able to create
symlinks. This also means that Windows XP is no longer
supported.
To transition a previously created checkout:
Run "python setup_links.py --force" to cleanup the old
SVN-based dependencies that have been synced by gclient sync.
For Buildbots, the --force flag is automatically enabled for
their syncs.
BUG=2863, chromium:339647
TEST=Manual testing on Linux, Mac and Windows.
R=andrew@webrtc.org, iannucci@chromium.org, phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/18379005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6938 4adac7df-926f-26a2-2b94-8c16560cd09d
There are currently a number of places in the code where we dump audio
data in various stages of processing for debug purposes. Currently
these all write raw, uncompressed PCM files, which isn't supported by
the most common audio players, and requires the user to supply
metadata such as sample rate, sample size and endianness, etc.
This patch adds a simple class that makes it easy to write WAV files
instead. WAV files still contain the same uncompressed PCM data, but
they have a small header that contains all the requisite metadata, and
are supported by virtually all audio players.
Since some of the debug code that will be writing WAV files is written
in plain C, a C API is included as well.
R=andrew@webrtc.org, bjornv@webrtc.org, henrike@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16809004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6932 4adac7df-926f-26a2-2b94-8c16560cd09d
These global arrays are shared amongst all AEC instances, and were at
serious risk of data races. A Chromium TSAN bot recently caught this.
Also move the function pointer selection for optimization to
create-time. (Ideally this would only be done once.)
BUG=chromium:404133,1503
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19069004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6922 4adac7df-926f-26a2-2b94-8c16560cd09d
When building WebRTC from a Chromium checkout (i.e. with
https://codereview.chromium.org/321313006/ applied) GN
cannot execute successfully.
This CL fixes:
- include path for video_processing module's SSE2 target.
- NSS/SSL targets
BUG=3441
TEST=
Passing WebRTC GN trybots.
Passing build from a Chromium checkout with https://codereview.chromium.org/321313006 applied and src/third_party/webrtc symlinked to the WebRTC checkout with this CL:
gn gen out/Default --args="clang_use_chrome_plugins=false" && ninja -C out/Default
gn gen out/Default --args="os=\"android\" cpu_arch=\"arm\" clang_use_chrome_plugins=false" && ninja -C out/Default
R=brettw@chromium.org
Review URL: https://webrtc-codereview.appspot.com/21179005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6921 4adac7df-926f-26a2-2b94-8c16560cd09d
The modification only uses the unique part of the spectrum (as is done for the C and asm code). It passes
byte to byte conformance test, and the single function performance
(if not specified, the code is compiled by GCC 4.6) on different
platforms:
| run 100k times | cortex-a7 | cortex-a9 | cortex-a15 |
| use C as the base on each | (1.2Ghz) | (1.0Ghz) | (1.7Ghz) |
| CPU target | | | |
|----------------------------+-----------+-----------+------------|
| C | 100% | 100% | 100% |
| Neon asm | 18% | 14% | 19% |
| Neon inline asm | 31% | 25% | 27% |
| Neon intrinsic (GCC 4.6) | 33% | 27% | 42% |
| Neon intrinscis (GCC 4.8) | 17% | 14% | 19% |
| Neon intrinsics (LLVM 3.3) | 15% | 13% | 18% |
BUG=
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/13739004
Patch from Joe Yu <joe.yu@arm.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6920 4adac7df-926f-26a2-2b94-8c16560cd09d
Previous updated_rect wasn't set for frames generated by WindowCapturer
implementation. That makes them unustable with chromoting host that
uses update_rect. With that change the frames will always contain
updated_rect that coveras the whole frame.
Change by Ronak Vora <ronakvora@google.com>
R=wez@chromium.org
Review URL: https://webrtc-codereview.appspot.com/22079004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6912 4adac7df-926f-26a2-2b94-8c16560cd09d
The bot that had the problem was using an old version of STL, so relanding.
> Revert 6863 "Refactor StatsCollector and associated types."
>
> Breaks chrome compilation on Mac:
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/vector.tcc:252:8:
> error: no matching constructor for initialization of
> 'webrtc::StatsReport'
> _Tp __x_copy = __x;
> ^ ~~~
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_vector.h:608:4:
> note: in instantiation of member function
> 'std::vector<webrtc::StatsReport, std::allocator<webrtc::StatsReport>
> >::_M_insert_aux' requested here
> _M_insert_aux(end(), __x);
> ^
> ../../content/renderer/media/mock_peer_connection_impl.cc:282:11:
> note: in instantiation of member function
> 'std::vector<webrtc::StatsReport, std::allocator<webrtc::StatsReport>
> >::push_back' requested here
> reports.push_back(report1);
> ^
> ../../third_party/libjingle/source/talk/app/webrtc/statstypes.h:49:3:
> note: candidate constructor not viable: requires 0 arguments, but 1
> was provided
> StatsReport() : timestamp(0) {}
>
>
>
> > Refactor StatsCollector and associated types.
> > * Due to the type changes, I'm going to update the OnCompleted event in two phases to sync with Chrome. This is the first phase.
> > * Reports are now managed in a set, not a map, since it's enough to store the id in one place.
> > * Report ids are now const.
> > * Copying of data has been greatly reduced.
> > * This change includes preparation work for making GetStats fully async.
> >
> > This is a reland of r6778 which was reverted due to fyi bots failing.
> > I found and fixed the issue which was that in a couple of places I needed to replace a report instead of finding+updating an existing one.
> >
> > R=xians@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/15119004
>
> TBR=tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/21169004TBR=niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22099004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6908 4adac7df-926f-26a2-2b94-8c16560cd09d
Macros should in general be avoided. WEBRTC_SPL_UMUL_32_16_RSFT16 is only used in iSAC fixed point as part of multiplying with LSB and MSB. A better approach is to have one function for that complete operation in iSAC.
This CL removes the macro and replace the operation locally.
BUG=3148, 3353
TESTED=locally on Linux and trybots
R=tina.legrand@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16349004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6907 4adac7df-926f-26a2-2b94-8c16560cd09d
Fixes issues where statistics only was reported for the first stream if
configured with simulcast, and in case of RTX the reported statistics was
depending on the order of the report blocks.
Also fixes issues with multiple report blocks in the SendStatisticsProxy and the
RtcpStatisticsCallback. SendStatisticsProxy is now aware of RTX ssrcs, and the
RTCPReceiver is calling the RtcpStatisticsCallback with the correct SSRCs, and
not only the primary stream SSRC.
R=mflodman@webrtc.org, sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20149004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6903 4adac7df-926f-26a2-2b94-8c16560cd09d
