The CL was reverted in r5712, due to bots going red. However, these bots
are unrelated to this CL.
Original description:
VideoSendStreamTest.SuspendBelowMinBitrate was flaky. The problem was
that when the first non-padding packet was sent after the stream was
resumed, the statistics had not always been updated so that
stats.suspended was false. After seeing the first non-padding packet
after suspension, the test will now go into a state where it waits for
the statistics to be changed.
BUG=3068
R=pbos@webrtc.orgTBR=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10099004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5713 4adac7df-926f-26a2-2b94-8c16560cd09d
VideoSendStreamTest.SuspendBelowMinBitrate was flaky. The problem was that when the first non-padding packet was sent after the stream was resumed, the statistics had not always been updated so that stats.suspended was false. After seeing the first non-padding packet after suspension, the test will now go into a state where it waits for the statistics to be changed.
BUG=3068
R=pbos@webrtc.orgTBR=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10069004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5711 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL adds support for reading .y4m files to the infra in
video_quality_analysis.cc, adding new functions
ExtractFrameFromYuvFile() and ExtractFrameFromY4mFile(),
instad of the previous ExtractFrameFromI420(). The decision
as to which one to use is taken from the file extension,
if it is .y4m then is considered a YUV4MPEG file, otherwise
is taken as a raw .yuv file.
It also removes the pseudo duplicated function
GetNextI420Frame(), that is used from psnr_ssim_analyzer.c,
and adds support for y4m files there.
Tested/validated via local compile-run.
YUV4MPEG is a trivial container with a file header
and a per-frame header, see [1]
[1]
http://wiki.multimedia.cx/index.php?title=YUV4MPEG2
BUG=https://code.google.com/p/chromium/issues/detail?id=343504
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5702 4adac7df-926f-26a2-2b94-8c16560cd09d
Wrote a new NetEq unit test to test a network freeze during comfort
noise playout. The network freezes and resumes during the silence
period, and then resumes speech. It was verified that the delay
increased due to the freeze, and this CL contains a fix for that
problem.
BUG=2995
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9849004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5701 4adac7df-926f-26a2-2b94-8c16560cd09d
In practice, this will have only marginal effect. The length_limit
was increased from 6.7 ms to 10 ms. This is compared with the
input_length, which is equal to the decoded frame size. Thus,
this change will only affect encoded frame sizes in this range
(including 10 ms).
BUG=2696
R=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9969004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5700 4adac7df-926f-26a2-2b94-8c16560cd09d
We've had problems that seem to manifest in run_tests.mm getting stuck
on exit. For our automated test targets only full_stack.cc was making
use of the platform-specific renderers provided by webrtc_test_common
and since no one currently monitors these the use case is hypothetical.
Readding platform-specific renderers to video_loopback is tracked with
issue 3039, though as far as I'm aware no one's currently using the
video_loopback target.
BUG=2987
R=kjellander@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9789004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5686 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL implements a unit test to cover an case where comfort noise
packets should be discarded. The situation arises when NetEq gets a
duplicate comfort noise packet. Without this check, the duplicate would
be decoded, and a the timing would shift.
As it turned out, the corner-case funcionality was not completely
accurate in NetEq4. This is because decision_logic_::cng_state_ is set
after the corner-case check. In the old NetEq3, the corresponding state
was changed before the check. This is now fixed.
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9639005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5685 4adac7df-926f-26a2-2b94-8c16560cd09d
Adding option to use mock or real objects instead of mocks.
This will help future testing efforts, where each test case can
select whether a mock or a real object should be used.
Adding new test InsertPacketsUntilBufferIsFull.
Removing a few uniteresting mock call warning.
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9839004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5684 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add an Initialize() overload to allow specification of format
parameters. This is mainly useful for testing, but could be used in
the cases where a consumer knows the format before the streams arrive.
- Add a reverse_sample_rate_hz_ parameter to prepare for mismatched
capture and render rates. There is no functional change as it is
currently constrained to match the capture rate.
- Fix a bug in the float dump: we need to use add_ rather than set_.
- Add a debug dump test for both int and float interfaces.
- Enable unpacking of float dumps.
- Enable audioproc to read float dumps.
- Move more shared functionality to test_utils.h, and generally tidy up
a bit by consolidating repeated code.
BUG=2894
TESTED=Verified that the output produced by the float debug dump test is
correct. Processed the resulting debug dump file with audioproc and
ensured that we get identical output. (This is crucial, as we need to
be able to exactly reproduce online results offline.)
R=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9489004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5676 4adac7df-926f-26a2-2b94-8c16560cd09d
Overview of changes in Chrome DEPS:
$ svn diff http://src.chromium.org/chrome/trunk/src/DEPS -r 249215:255773
which can be compared with the output of:
$ grep chromium_deps DEPS
in a WebRTC checkout, gives the following relevant changes:
* third_party/icu 246118:249466
* third_party/libyuv 978:979
* third_party/libjpeg_turbo 239595:251747
* third_party/libsrtp 214783:250757
* third_party/nss 246067:254867
* tools/clang-format 198831:202065
* tools/gyp 1846:1860
Among a variety of updated DEPS, this enables us to use
the new automatic download of Chromium's stripped down
Visual Studio 2013 toolchain on Windows.
For Windows, Visual Studio 2013 is also the default compiler
in Chrome. This CL sets the GYP_MSVS_VERSION to 2010 unless
otherwise specified. Doing that we can first fix our 2013 problems
before we move over to having 2013 by default.
The plan is to build 2013 at the WebRTC FYI waterfall at
http://build.chromium.org/p/client.webrtc.fyi/waterfall
to ensure we can support VS2013 before the switch.
I realized we can sync Chromium's find_depot_tools.py script
into it's own folder and just alter the PYTHONPATH for the
gyp_webrtc script. That way there's no need to have the dummy
module in webrtc/build anymore. The real script is also needed
for the logic that handles checking VS2013 and downloading it if
not found.
BUG=chromium:340973
TEST=All trybots passing runhooks and compile step.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5667 4adac7df-926f-26a2-2b94-8c16560cd09d
