The variable playout_timestamp_ was not updated to the latest decoded
timestamp while comfort noise was played. Instead, it was upadted using
dead reckoning, which caused it to drift away from the timestamps of the
incoming CNG packets. Now it is updated also during comfort noise
playout.
Since the change is only in NetEq4, this change also makes the test
PlaysOutAudioAndVideoInSync use both ACM1/NetEq3 and ACM2/NetEq4.
Re-enabling one NetEq unit test that is no longer failing thanks to this CL.
BUG=2932
R=stefan@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8799004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5649 4adac7df-926f-26a2-2b94-8c16560cd09d
Analogous to the recent libjingle change: http://cl/54929753-p10.
This supports scoped_ptr<T[]> and scoped_ptr<C, FreeDeleter> rather
than scoped_array and scoped_ptr_malloc respectively.
- Add Chromium's template-based COMPILE_ASSERT. We didn't have this
previously in order to support the macro in C. Instead, move the
existing macro to compile_assert_c.h.
- Additionally copy the move.h and template_util.h depedencies and add
the WARN_UNUSED_RESULT macro.
- Leave scoped_array and scoped_ptr_malloc for now, but mark as
deprecated.
- Remove scoped_ptr foo(NULL) use. The default constructor handles it.
- Remove the now redundant COMPILE_ASSERT from peerconnection_jni.cc.
- Add a CHECK_ARRAY_SIZE macro to rtp_format_vp8_unittest.cc to remove
some repeated code.
TESTED=trybots
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2449005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5015 4adac7df-926f-26a2-2b94-8c16560cd09d
We encounter a sample-underrun if NetEq is initialized with a sampling rate fs =16000 and receive Opus packets with frame-size less than 5 ms. The reason is as follows.
Let say NetEq buffer has 4 packets of Opus each of size 2.5ms this means that internally timestamp of packets incremented by 80 (internally Opus treated as 32 kHz codec). Given the initial sampling rate of NetEq, at the first time that it wants to fetch packets, it targets to fetch 160 samples. Therefore, it will only extracts 2 packets. Decoding these packets give us exactly 160 samples (5 ms at 32 kHz), however, upon decoding the first packet the internal sampling rate will be updated to 32 kHz. So it is expected that sync buffer to deliver 320 samples while it does only have 160 samples (or maybe few more as it starts with some zeros). And we encounter and under-run.
Even if we ignore the under-run "assert(sync_buffer_->FutureLength() >= expand_->overlap_length())" (neteq_impl.cc::811) is trigered. I'm not sure what happens if we remove this assert perhaps NetEq will work fine in subsequent calls. However the first under-run is blocking ACM2 test to pass.
Here I have a solution to update sample rate as soon as a packet is inserted, if required. It not a very efficient approach as we do the same reset in NetEqImpl::Decode().
It is a bit tricky to reproduce this because the TOT ACM tests do not run ACM2. In https://webrtc-codereview.appspot.com/2192005/ I have a patch to run both ACMs. To reproduce the problem, one can patch that CL and run
$ out/Debug/modules_tests --gtest_filter=AudioCodingModuleTest.TestOpus
Note that we would not encounter any problem if NetEq4 is initiated with 32000 Hz sampling rate. You can test this by setting |kNeteqInitSampleRateHz| to 32000 in webrtc/modules/audio_coding/main/acm2/acm_receiver.cc
BUG=
R=andrew@webrtc.org, henrik.lundin@webrtc.org, kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2306004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4896 4adac7df-926f-26a2-2b94-8c16560cd09d
However, two other "hacks" had to be added to maintain bit-exactness
with legacy.
Note that this change requires a new version of the universal.rtp test
input, although the output reference stays the same.
Moving reference files, and using a new input vector for NetEq4.
The new input vector neteq_universal_new.rtp is identical to the old
neteq_universal.rtp, except that the payload type for CNG packets that
follows a wideband codec is changed to 98.
Update to resources revision 15 where the new reference files are.
Also changing a faulty log error.
Review URL: https://webrtc-codereview.appspot.com/1078009
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3442 4adac7df-926f-26a2-2b94-8c16560cd09d