Mostly, it's about moving constructors and descructors to the .cc
files, so that they won't be inlined everywhere.
The reason this CL is so big is that a lot of code was using
common_types.h without declaring a dependency on webrtc_common, which
broke the build once common_types.h started to depend on
common_types.cc.
BUG=163
R=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26089004
Cr-Commit-Position: refs/heads/master@{#8516}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8516 4adac7df-926f-26a2-2b94-8c16560cd09d
Add some const safety by DCHECK(HasOneRef()) in non-const GetYPlane. This CL also replaces all incorrect non-const calls with const calls for pixel data access in cricket::VideoFrame. It's easy to call the non-const version of e.g. GetYPlane by mistake, even if only const-access is needed. For example:
const scoped_ptr<cricket::VideoFrame> foo;
const uint8_t* y = foo->GetYPlane();
will actually call the non-const version of GetYPlane.
R=mflodman@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39079004
Cr-Commit-Position: refs/heads/master@{#8507}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8507 4adac7df-926f-26a2-2b94-8c16560cd09d
TestScaler::ComputeAvgSequencePSNR is currently a complex NOP, that always returns kPerfectPSNR. Two frames are read from files into arrays, and then converted into I420VideoFrames. However, the incorrect function ConvertFromI420 is used instead of ConvertToI420, resulting in two empty I420VideoFrames. I420PSNR on empty frames returns kPerfectPSNR.
This CL replaces ConvertFromI420 with ConvertToI420 and actually measures the PSNR. Unfortunately, some tests do not pass when we use the real psnr. The tests that fail are the ones that scale back and forth to a different aspect ratio. webrtc::Scaler has been changed to preserve aspect ratio, and this means that we will end up with a cropped frame if scale and rescale to a different target aspect ratio. I simply removed those tests to make it pass. Having some working tests instead of a lot of dummy tests seems like a win.
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35339004
Cr-Commit-Position: refs/heads/master@{#8506}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8506 4adac7df-926f-26a2-2b94-8c16560cd09d
Call to AudioEncoder::Encode fails only if fed bad input, so instead of handling failure, we can just CHECK.
There is also no need to handle case where size of encoded data is larger than allowed maximum, so we just CHECK.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42099005
Cr-Commit-Position: refs/heads/master@{#8504}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8504 4adac7df-926f-26a2-2b94-8c16560cd09d
This should be safe to land now that issue 4143 was resolved (in r8492).
This change effectively reverts 8488.
TBR=kwiberg@webrtc.org
Original commit message:
This CL changes the way the decoder sample rate is set and updated. In
practice, it only concerns the iSAC (float) codec.
One single iSAC decoder instance is used for both wideband and
super-wideband decoding, and the instance must be told to switch
output frequency if the payload type changes. This used to be done
through a call to UpdateDecoderSampleRate, but is now instead done in
the Decode call as an extra parameter.
Review URL: https://webrtc-codereview.appspot.com/39289004
Cr-Commit-Position: refs/heads/master@{#8496}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8496 4adac7df-926f-26a2-2b94-8c16560cd09d
Without this patch, Valgrind's Memcheck was complaining that the test
for whether we should return -1 following the call to
WebRtcIsac_DecodeLb made a conditional branch or move based on the
value of numSamplesLB, which was uninitialized if WebRtcIsac_DecodeLb
failed.
However, as can be seen in the source, the control flow only depends
on the value of numSamplesLB if numDecodedBytesLB >= 0; i.e., if
WebRtcIsac_DecodeLb returned successfully, in which case numSamplesLB
is always initialized. The discrepancy is due to the fact that
Valgrind works on the generated machine code, which contains spurious
such dependencies. The generated code for this test:
if ((numDecodedBytesLB < 0) || (numDecodedBytesLB > lenEncodedLBBytes) ||
(numSamplesLB > MAX_FRAMESAMPLES)) {
looks like this:
95: 0f bf 45 d6 movswl -0x2a(%rbp),%eax
99: 3d c0 03 00 00 cmp $0x3c0,%eax
9e: 0f 8f 45 01 00 00 jg 1e9 <Decode+0x1e9>
a4: 44 89 f0 mov %r14d,%eax
a7: c1 e0 10 shl $0x10,%eax
aa: 0f 88 39 01 00 00 js 1e9 <Decode+0x1e9>
b0: 41 0f bf ce movswl %r14w,%ecx
b4: 89 8d 98 e1 ff ff mov %ecx,-0x1e68(%rbp)
ba: 41 0f bf c7 movswl %r15w,%eax
be: 39 c1 cmp %eax,%ecx
c0: 0f 8f 23 01 00 00 jg 1e9 <Decode+0x1e9>
Note how the compiler has seemingly ignored the C language's guarantee
that the arguments to || must be evaluated in left-to-right order, and
compares numSamplesLB (%eax) with MAX_FRAMESAMPLES (0x3c0, a.k.a. 960)
before the other two conditions! If the uninitialized value in
numSamplesLB happens to be greater than 960, we'll jump to
Decode+0x1e9 (where we'll return -1) without even looking at the other
two conditions. Has the compiler generated broken code?
Well, no. If numDecodedBytesLB is < 0 so that numSamplesLB is
uninitialized, we'll end up jumping to 1e9 whether that value is
greater than 960 or not; we'll just do it with different jump
instructions. This is entirely invisible as far as the C language is
concerned, but the dependency on the uninitialized value is visible at
the machine code level, which is why Memcheck complains.
This patch solves the problem by pragmatically initializing
numSamplesLB before the call even though it isn't necessary other than
for placating Memcheck.
BUG=4143
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36309004
Cr-Commit-Position: refs/heads/master@{#8492}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8492 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL changes the way the decoder sample rate is set and updated. In
practice, it only concerns the iSAC (float) codec.
One single iSAC decoder instance is used for both wideband and
super-wideband decoding, and the instance must be told to switch
output frequency if the payload type changes. This used to be done
through a call to UpdateDecoderSampleRate, but is now instead done in
the Decode call as an extra parameter.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34349004
Cr-Commit-Position: refs/heads/master@{#8476}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8476 4adac7df-926f-26a2-2b94-8c16560cd09d
Calls to WebRtcCng_Encode, AudioEncoder::Encode and Vad::VoiceActivity fail only if fed bad input, so instead of handling failure, we can just CHECK. This also makes it unnecessary for methods AudioEncoderCng::EncodePassive and AudioEncoderCng::EncodeActive to return a value, so we can make them void.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39279004
Cr-Commit-Position: refs/heads/master@{#8475}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8475 4adac7df-926f-26a2-2b94-8c16560cd09d
* Move constants into the files/functions that use them
* Declare variables in the narrowest scope possible
* Use correct (expected, actual) order for gtest macros
* Remove unused functions
* Untabify
* 80-column limit
* Avoid C-style casts
* Prefer true typed constants to "enum hack" constants
* Print size_t using the right format macro
* Shorten and simplify code
* Other random cleanup bits and style fixes
BUG=none
TEST=none
R=henrik.lundin@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36179004
Cr-Commit-Position: refs/heads/master@{#8467}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8467 4adac7df-926f-26a2-2b94-8c16560cd09d
ACMGenericCodecWrapper was the only remaining subclass of
ACMGenericCodec, and was the only class that was ever instantiated.
This CL merges the two, essentially keeping the function implementations
from ACMGenericCodecWrapper except where the base class's code was
invoked.
As it turns out, a lot of functions were never used, but in some cases
they were refernced in AudioCodingModuleImpl. In these cases, the
referencing code is commented out and marked FATAL(). This will be
further cleaned up in follow-up CLs.
BUG=4228
COAUTHOR=kwiberg@webrtc.orgR=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38209004
Cr-Commit-Position: refs/heads/master@{#8463}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8463 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL is part II in a major refactoring effort. See https://webrtc-codereview.appspot.com/33969004 for part I.
- Removes unused code and old WEBRTC logging macros
- Now uses optimal sample rate and buffer size in Java AudioTrack (used hard-coded sample rate before)
- Makes code more inline with the implementation in Chrome
- Adds helper methods for JNI handling to improve readability
- Changes the threading model (high-prio audio thread now lives in Java-land and C++ only works as proxy)
- Simplified the delay estimate
- Adds basic thread checks
- Removes all locks in C++ land
- Removes all locks in Java
- Improves construction/destruction
- Additional cleanup
Tested using AppRTCDemo and WebRTCDemo APKs on N6, N5, N7, Samsung Galaxy S4 and
Samsung Galaxy S4 mini (which uses 44.1kHz as native sample rate).
BUG=NONE
R=magjed@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39169004
Cr-Commit-Position: refs/heads/master@{#8460}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8460 4adac7df-926f-26a2-2b94-8c16560cd09d
They have all been replaced by AudioEncoder subclasses, accessed throgh
ACMGenericCodecWrapper objects. After this change, the only subclass of
ACMGenericCodec is ACMGenericCodecWrapper. (The two will be consolidated
in a future cl.)
This CL also deletes acm_opus_unittest.cc. This test file was already
replaced audio_encoder_opus_unittest.cc in r8244.
BUG=4228
COAUTHOR=kwiberg@webrtc.orgR=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40729004
Cr-Commit-Position: refs/heads/master@{#8457}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8457 4adac7df-926f-26a2-2b94-8c16560cd09d
This cl just moves the logic form the default module
SetTargetSendBitrates to PayloadRouter. There might be glitch / mismatch
in size between trate the vector and rtp modules. This was the same in
the default module and is quite hard to protect from before we have the
new video API.
I also removed some test form rtp_rtcp_impl_unittest that were affected
by this change. The test tests code that isn't implemented, hence the
DISABLED_, and this will never be implemented in the RTP module, rather
the payload router in the future.
BUG=769
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42419004
Cr-Commit-Position: refs/heads/master@{#8453}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8453 4adac7df-926f-26a2-2b94-8c16560cd09d
There is a potential race when deleting a channel and there is a frame
in the encoder. ViEEncoder::SendData can be called after
ViEEncoder::StopThreadsAndRemovePayloadRouter and payload_router is
then already removed.
Until we have the new API in place, use scoped_refptr in ViEChannel and
ViEEncoder and deregister channel/encoder before deleting.
BUG=769
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42019004
Cr-Commit-Position: refs/heads/master@{#8443}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8443 4adac7df-926f-26a2-2b94-8c16560cd09d
* Don't use ConjugateDotProduct to calculate the norm.
* Only resize Matrix when needed.
This makes the Beamformer run in 93.6% the original time.
The error between the new and original output is really small and is caused by the new norm calculation.
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37339004
Cr-Commit-Position: refs/heads/master@{#8438}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8438 4adac7df-926f-26a2-2b94-8c16560cd09d
Fetching the current codec for sake of gathering stats, is frequently blocked since it's done by acquiring the same lock as is held while encoding frames. This can mean tens of milliseconds.
To improve this, I'm taking advantage of the fact that the codec information is set on the same thread as is used to query the information. This means that locking isn't needed for querying this information. I'm adding checks to make sure debug builds will crash if this isn't followed.
An alternative to this approach could be to add one more lock that is specifically used for the codec information variable. This would also decouple querying codec information from the encoder itself, but still requires a lock.
This patch depends on making ThreadChecker part of rtc_base_approved:
https://webrtc-codereview.appspot.com/40539004/
BUG=2822
R=mflodman@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37779004
Cr-Commit-Position: refs/heads/master@{#8435}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8435 4adac7df-926f-26a2-2b94-8c16560cd09d
