d9faa46d57
Changing to using factory methods for some classes in NetEq
...
In this CL, the Expand, Accelerate and PreemptiveExpand objects are
created using factory methods. The factory methods are injected into
NetEqImpl on creation. This is a step towards implementing a no-decode
operation.
BUG=2776
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6999005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5382 4adac7df-926f-26a2-2b94-8c16560cd09d
2014-01-14 10:18:45 +00:00
58cd31665c
Address Clag Analyzer issues.
...
Following are the issues related to NetEq 4, discovered by Clang Analyzer.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-b44b95.html#EndPath
Valid; perhaps unlikely, addressed.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-6beef6.html#EndPath
Valid, addressed.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-2e3883.html#EndPath
Valid; Addressed
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-293659.html#EndPath
Valid; Addressed.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-b875cd.html#EndPath
Valid; Addressed.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/index.html
Not valid;
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-86f2ed.html#EndPath
Not Valid; the assert statement will be short-circuited, however I also added a check of nullity of |packet|.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-3a5669.html#EndPath
Not Valid: |energy_input| and |energy_expand| are both non-negative, therefore if-statement condition on line 226 is not satisfied unless |energy_input| >= 1. Therefore |energy_input| cannot be zero after normalization to 14-bits, i.e. operations on lines 228 & 229.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-2f914f.html#EndPath
Valid; addressed.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-2332b1.html#EndPath
Valid; addressed.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-de8dea.html#EndPath
Not valid; |out_len| is set when Process() is called, however, it makes sense to initialize to zero when declaring |out_len|.
https://x20web.corp.google.com/~pbos/scan-build-2013-10-10-1/report-b671a3.html#EndPath
Valid; addressed.
BUG=
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2729005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5064 4adac7df-926f-26a2-2b94-8c16560cd09d
2013-10-31 15:15:55 +00:00
fd11bbfb56
NetEq4: Removing templatization for AudioMultiVector
...
This saves approx 6% runtime for neteq4_speed_test.
$ time out/Release/neteq4_speed_test --runtime_ms=50000000
BUG=1363
R=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2320006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4885 4adac7df-926f-26a2-2b94-8c16560cd09d
2013-09-30 20:38:44 +00:00
ff43c85ef1
API add to set background noise mode.
...
Background noise mode.
BUG=
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2194005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4835 4adac7df-926f-26a2-2b94-8c16560cd09d
2013-09-25 00:07:27 +00:00
362a55e7b0
Address Windows 64-bits warnings.
...
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2203004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4803 4adac7df-926f-26a2-2b94-8c16560cd09d
2013-09-20 16:25:28 +00:00
12dc1a38ca
Switch C++-style C headers with their C equivalents.
...
The C++ headers define the C functions within the std:: namespace, but
we mainly don't use the std:: namespace for C functions. Therefore we
should include the C headers.
BUG=1833
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1917004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4486 4adac7df-926f-26a2-2b94-8c16560cd09d
2013-08-05 16:22:53 +00:00
7126b38d8f
Handel zero correlation if at the same time distortion is also zero.
...
This is the conversation I had with Henrik Lundin regarding this problem.
Me:
In Expand::AnalyseSignal() we compute correlation and distortion, then calculate the ratio of correlation to distortion. There if distortion is zero we expect that correlation to be zero. Although in practice this might be true, I suppose we rarely hit into absolutely periodic signal, but in one of the tests the assertion in line 455 of expand.cc was triggered. The distortion is computed over a shorter length of the signal, while correlation is computed over longer segments. Therefore, I guess, if the signal has just enough zeros at the beginning we can end up in situation that distortion is zero but not the correlation. Do you agree? I didn't have time to attempt to solve this, but if my line of thought is correct, we should not have that assert. Perhaps, if correlation is zero we set the ratio to 0, otherwise, ratio would be the largest value of its own type. Any thoughts?
Henrik:
I agree with you. Go ahead with your solution.
R=minyue@google.com
Review URL: https://webrtc-codereview.appspot.com/1888006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4448 4adac7df-926f-26a2-2b94-8c16560cd09d
2013-07-31 16:05:09 +00:00
d94659dc27
Initial upload of NetEq4
...
This is the first public upload of the new NetEq, version 4.
It has been through extensive internal review during the course of
the project.
TEST=trybots
Review URL: https://webrtc-codereview.appspot.com/1073005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3425 4adac7df-926f-26a2-2b94-8c16560cd09d
2013-01-29 12:09:21 +00:00
