Due to a bug in the RTP module, which appeared during packet loss, we have had too short delay in the Win Large Test. When the bug was fixed we had a regression error that should be fixed with this update.
Review URL: https://webrtc-codereview.appspot.com/1091005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3466 4adac7df-926f-26a2-2b94-8c16560cd09d
The big benefit is we no longer have a circular dependency between the media receiver and the payload registry. The payload registry is starting to take a bit more place on the stage, and now knows how to do different things depending on audio or video.
BUG=
TESTED=rtp_rtcp_unittests, vie_auto_test, voe_auto_test
Review URL: https://webrtc-codereview.appspot.com/1078004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3465 4adac7df-926f-26a2-2b94-8c16560cd09d
A reverse copy is removed. The index to src buffer could be -1, this happens very often. The reverse copy is not needed as the content of the destination is overwritten further down in "WebRtcIlbcfix_CbConstruct()"
Bug=issue281
TEST=manual test over 1600 files TIMIT database, all outputs are bit-exact with the ones generated from head revision. Local run of asan does not generate any warning.
Review URL: https://webrtc-codereview.appspot.com/1063013
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3447 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
The changes in r1068 that moved over to the webrtc/test/buildbot_tests.py launch script was not properly tested on the real machine for the audio_e2e_test. Due to that it contained a few syntax errors and paths that were not resolved as expected. This CL fixes this and has been tested more thorougly.
BUG=none
TEST=Ran, standing in the checkout dir:
out/Release/buildbot_tests.py -t audio_e2e_test
with successful result.
Review URL: https://webrtc-codereview.appspot.com/1070012
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3438 4adac7df-926f-26a2-2b94-8c16560cd09d
> Delay estimator wrapper API changes. This should finalize the changes to delay estimator making it work for multi-probe.
>
> The changes are summarized here:
>
> delay_estimator.*
> -----------------
> Replaced assert() with correct error check. This is consistent with previous versions of the delay_estimator, i.e., to check for valid parameters where they are actually used and not high up in a wrapper layer.
>
> delay_estimator_internal.h
> --------------------------
> Pulled out the far-end part of DelayEstimator struct and put it in DelayEstimatorFarend. The only common parameter is spectrum_size, which we store in both and thereby avoiding having a Farend pointer in DelayEstimator.
>
> delay_estimator_wrapper.*
> -------------------------
> Added and updated descriptions. From Free(), Create(), Init() the far-end parts have been put in separate Farend versions. Same goes for the Process() which now has an AddFarSpectrum() version.
> The flow of calls should be something like (in pseudo-code)
>
> far* = CreateFarend(history_size)
> near* = Create(far, lookahead)
> InitFarend(far)
> Init(near)
> while call ongoing
> AddFarSpectrum(far, far_spectrum)
> Process(near, near_spectrum)
> end while
> Free(near)
> FreeFarend(far)
>
> delay_estimator_unittest.cc
> ---------------------------
> Added farend support setting up calls as mentioned above.
>
> aecm_core.*
> -----------
> Cleaned up some lint warnings.
> Added delay_estimator_farend pointer. Called Create(), Init() and Free() in above mentioned order.
> If AddFarSpectrumFix() was not successfully done, we end and return -1. This is what we would have done for Process().
>
> aec_core.*
> ----------
> Cleaned up some lint warnings.
> Added delay_estimator_farend pointer. Calls in proper order. Since we only use the delay estimator for logging there is no error handling. We only call Process() if AddFarSpectrum() was successful though.
>
> TEST=audioproc_unittest, trybots
> BUG=None
>
> Review URL: https://webrtc-codereview.appspot.com/1076006TBR=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1062008
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3429 4adac7df-926f-26a2-2b94-8c16560cd09d
The changes are summarized here:
delay_estimator.*
-----------------
Replaced assert() with correct error check. This is consistent with previous versions of the delay_estimator, i.e., to check for valid parameters where they are actually used and not high up in a wrapper layer.
delay_estimator_internal.h
--------------------------
Pulled out the far-end part of DelayEstimator struct and put it in DelayEstimatorFarend. The only common parameter is spectrum_size, which we store in both and thereby avoiding having a Farend pointer in DelayEstimator.
delay_estimator_wrapper.*
-------------------------
Added and updated descriptions. From Free(), Create(), Init() the far-end parts have been put in separate Farend versions. Same goes for the Process() which now has an AddFarSpectrum() version.
The flow of calls should be something like (in pseudo-code)
far* = CreateFarend(history_size)
near* = Create(far, lookahead)
InitFarend(far)
Init(near)
while call ongoing
AddFarSpectrum(far, far_spectrum)
Process(near, near_spectrum)
end while
Free(near)
FreeFarend(far)
delay_estimator_unittest.cc
---------------------------
Added farend support setting up calls as mentioned above.
aecm_core.*
-----------
Cleaned up some lint warnings.
Added delay_estimator_farend pointer. Called Create(), Init() and Free() in above mentioned order.
If AddFarSpectrumFix() was not successfully done, we end and return -1. This is what we would have done for Process().
aec_core.*
----------
Cleaned up some lint warnings.
Added delay_estimator_farend pointer. Calls in proper order. Since we only use the delay estimator for logging there is no error handling. We only call Process() if AddFarSpectrum() was successful though.
TEST=audioproc_unittest, trybots
BUG=None
Review URL: https://webrtc-codereview.appspot.com/1076006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3428 4adac7df-926f-26a2-2b94-8c16560cd09d
pthread_t is a pointer type on Mac OS X, and is thus 32 bits wide in the
32-bit environment and 64 bits wide in the 64-bit environment. WebRTC's
thread ID routines assume that thread IDs can always fit inside a uint32_t,
but this is not the case in the 64-bit Mac environment when using pthread_t
as the basis for a thread ID. Instead, switch to using the underlying Mach
port for the thread, which is a 32-bit quantity in both the 32-bit and 64-bit
environments.
The only place this seems to be used is in TraceImpl::AddThreadId, and it's
only used there for a thread ID for display.
This is a better fix than https://webrtc-codereview.appspot.com/929015 .
Review URL: https://webrtc-codereview.appspot.com/1063005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3427 4adac7df-926f-26a2-2b94-8c16560cd09d
By changing the working directory for the executing script to the same
directory as the script is located in, it is possible to run the script
standing in a higher-level directory (otherwise the input file relative
paths become invalid).
This CL also changes the input file path for the audio_e2e_test test to
assume the file is located resources.
BUG=none
TEST=locally executed the tests standing in trunk/
Review URL: https://webrtc-codereview.appspot.com/1061009
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3422 4adac7df-926f-26a2-2b94-8c16560cd09d
With http://review.webrtc.org/1064004 we got use of headers in testing/ for the first time in production code (which is what gtest_prod.h is meant for). This showed that when WebRTC is built inside Chrome, the include path doesn't include the top-level directory, so testing/gtest/ could not be found.
By adding <(DEPTH) to the WebRTC global include path list in common.gypi, this is resolved.
Having this directory in the global include path list will also make it possible for us to use full paths for common third party libraries, which should be something we aim for.
BUG=none
TEST=Successfully compiled the webrtc_test_tools target on Linux in a Chromium checkout with third_party/webrtc replaced by ToT trunk with this patch applied (with Python 2.6 installed, which is needed to get the pyautolib target generated).
Review URL: https://webrtc-codereview.appspot.com/1082004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3421 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL is one step in a larger change of the DelayEstimator where we will open up for multiple near-end signals.
This particular CL separates the low level far-end parts without affecting the usage externally. This is a first step towards separating the far-end and near-end parts giving the user the control.
BUG=None
TEST=audioproc_unittests, trybots
Review URL: https://webrtc-codereview.appspot.com/1068005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3415 4adac7df-926f-26a2-2b94-8c16560cd09d
The path in test.gyp in r3411 was incorrect since it was based on the symlink that does not exist on Windows.
This CL changes it to reference the actual path in /tools/perf
TBR=phoglund
BUG=none
TEST=win try bot.
Review URL: https://webrtc-codereview.appspot.com/1074006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3413 4adac7df-926f-26a2-2b94-8c16560cd09d
