The macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) ((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definition on ARMv7 and MIPS, see
common_audio/signal_processing/include/spl_inl_armv7.h and
common_audio/signal_processing/include/spl_inl_mips.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int
or int32_t)
Some other minor code cleanup also exists.
BUG=3348,3353
TESTED=locally on Mac and trybots
R=henrik.lundin@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42639004
Cr-Commit-Position: refs/heads/master@{#8717}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8717 4adac7df-926f-26a2-2b94-8c16560cd09d
The current way that iSAC RCU is packetized and sent as a RED packet,
with the same payload type for primary and redundant payloads, does
not follow the specification for RED. As it is now, it is impossible
for a receiver to know if an incoming RED packet with iSAC payloads
inside consists of two "primary" (but time-shifted) payloads, or one
primary and one RCU payload. The RED standard stipulates that the
former option is the correct interpretation, while our implementation
currently applies the latter.
This CL removes support for iSAC RCU from Audio Coding Module, but
leaves it in the iSAC codec itself (i.e., in the C implementation).
BUG=4402
COAUTHOR=kwiberg@webrtc.orgR=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45569004
Cr-Commit-Position: refs/heads/master@{#8713}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8713 4adac7df-926f-26a2-2b94-8c16560cd09d
Removes ThreadPosix::InitParams and a corresponding wait for an event.
This unblocks ThreadPosix::Start which had to wait for thread scheduling
for an event to trigger on the spawned thread, giving faster Start()
calls.
BUG=4413
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43699004
Cr-Commit-Position: refs/heads/master@{#8709}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8709 4adac7df-926f-26a2-2b94-8c16560cd09d
- Remove unnecessary window member from lapped_transform.
- Add comment indicated that Blocker does not take ownership of
the window passed to its constructor.
- Streamline LappedTransform constructor so members can be const.
Also use a range-based for loop in audio_processing_impl.cc for clarity.
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41229004
Cr-Commit-Position: refs/heads/master@{#8708}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8708 4adac7df-926f-26a2-2b94-8c16560cd09d
Landing this on behalf of malmnas@.
The semantics is as follows:
* if the output filename is empty, then don't log to file
* if the input filename is empty, then don't stream any audio from file
This is useful for long running tests with multiple participants.
With logging turned on, having 10 bots running for 2 hours results in
more then 7 GB of data.
BUG=None
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41219004
Cr-Commit-Position: refs/heads/master@{#8691}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8691 4adac7df-926f-26a2-2b94-8c16560cd09d
Added method AudioEncoder::MaxEncodedBytes() and provided implementations in derived encoders. This method returns the number of bytes that can be produced by the encoder at each Encode() call.
Unit tests were updated to use the new method.
Buffer allocation was not changed in AudioCodingModuleImpl::Encode(). It will be done after additional investigation.
Other refactoring work that was done, that may not be obvious why:
1. Moved some code into AudioEncoderCng::EncodePassive() to make it more consistent with EncodeActive().
2. Changed the order of NumChannels() and RtpTimestampRateHz() declarations in AudioEncoderG722 and AudioEncoderCopyRed classes. It just bothered me that the order was not the same as in AudioEncoder class and its other derived classes.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40259005
Cr-Commit-Position: refs/heads/master@{#8671}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8671 4adac7df-926f-26a2-2b94-8c16560cd09d
The macro is defined as
#define WEBRTC_SPL_MUL_16_16_RSFT(a, b, c) \
(WEBRTC_SPL_MUL_16_16(a, b) >> (c))
where the latter macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) \
((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definitions on ARMv7 and MIPS, see common_audio/signal_processing/include/spl_inl_{armv7,mips}.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int or int32_t)
- minor cleanups like remove of unnecessary parentheses and style changes
BUG=3348,3353
TESTED=Locally on Mac and trybots
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41149004
Cr-Commit-Position: refs/heads/master@{#8666}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8666 4adac7df-926f-26a2-2b94-8c16560cd09d
The macro is defined as
#define WEBRTC_SPL_MUL_16_16_RSFT(a, b, c) \
(WEBRTC_SPL_MUL_16_16(a, b) >> (c))
where the latter macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) \
((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definitions on ARMv7 and MIPS, see common_audio/signal_processing/include/spl_inl_{armv7,mips}.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int or int32_t)
- minor cleanups like remove of unnecessary parentheses and style changes
In addition an implicit cast from int32_t to int16_t was removed, which was a bug.
BUG=3348,3353
TESTED=Locally on Mac and trybots
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41169004
Cr-Commit-Position: refs/heads/master@{#8665}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8665 4adac7df-926f-26a2-2b94-8c16560cd09d
The macro is defined as
#define WEBRTC_SPL_MUL_16_16_RSFT(a, b, c) \
(WEBRTC_SPL_MUL_16_16(a, b) >> (c))
where the latter macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) \
((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definitions on ARMv7 and MIPS, see common_audio/signal_processing/include/spl_inl_{armv7,mips}.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int or int32_t)
- minor cleanups like remove of unnecessary parentheses and style changes
BUG=3348,3353
TESTED=locally on Mac and trybots
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47449004
Cr-Commit-Position: refs/heads/master@{#8664}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8664 4adac7df-926f-26a2-2b94-8c16560cd09d
The macro is defined as
#define WEBRTC_SPL_MUL_16_16_RSFT(a, b, c) \
(WEBRTC_SPL_MUL_16_16(a, b) >> (c))
where the latter macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) \
((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definitions on ARMv7 and MIPS, see common_audio/signal_processing/include/spl_inl_{armv7,mips}.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int or int32_t)
- minor cleanups like remove of unnecessary parentheses and style changes
In addition an implicit cast from int32_t to int16_t was removed, which was a bug.
BUG=3348, 3353
TESTED=Locally on Mac and trybots
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41179004
Cr-Commit-Position: refs/heads/master@{#8653}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8653 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL adds support for unittests of the AudioDeviceModule on Android using both Java and C++. The new framework uses ::testing::TesWithParam to support both Java-based audio and OpenSL ES based audio. However, given existing issues in our OpenSL ES implementation, the list of test parameters only contains Java in this first version. Open SL ES will be enabled as soon as the backend has been refactored.
It also:
- Removes the redundant JNIEnv* argument in webrtc::VoiceEngine::SetAndroidObjects().
- Modifies usage of enable_android_opensl and the WEBRTC_ANDROID_OPENSLES define.
- Adds kAndroidJavaAudio and kAndroidOpenSLESAudio to AudioLayer enumerator.
- Fixes some bugs which were discovered when running the tests.
BUG=NONE
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40069004
Cr-Commit-Position: refs/heads/master@{#8651}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8651 4adac7df-926f-26a2-2b94-8c16560cd09d
> Speculative revert of 8631 "Remove lock from Bitrate() and FrameRate() in Video..."
>
> We ran into the alignment problem on Mac 10.9 debug again. This is the only CL I see in the range that adds an rtc::CriticalSection, so I'm trying out reverting it before attempting another roll.
>
> > Remove lock from Bitrate() and FrameRate() in VideoSender.
> > These methods are called on the VideoSender's construction thread, which is the same thread as modifies the value of _encoder. It's therefore safe to not require a lock to access _encoder on this thread.
> >
> > I'm making access to the rate variables from VCMGenericEncoder, thread safe, by using a lock that's not associated with the encoder. There should be little to no contention there. While modifying VCMGenericEncoder, I noticed that a couple of member variables weren't needed, so I removed them.
> >
> > The reason for this change is that getStats is currently contending with the encoder when Bitrate() is called. On my machine, this means that getStats can take about 25-30ms instead of ~1ms.
> >
> > Also adding some documentation for other methods and a suggestion for how we could avoid contention between the encoder and the network thread.
> >
> > BUG=2822
> > R=mflodman@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/43479004
>
> TBR=tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/45529004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46519004
Cr-Commit-Position: refs/heads/master@{#8645}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8645 4adac7df-926f-26a2-2b94-8c16560cd09d
We ran into the alignment problem on Mac 10.9 debug again. This is the only CL I see in the range that adds an rtc::CriticalSection, so I'm trying out reverting it before attempting another roll.
> Remove lock from Bitrate() and FrameRate() in VideoSender.
> These methods are called on the VideoSender's construction thread, which is the same thread as modifies the value of _encoder. It's therefore safe to not require a lock to access _encoder on this thread.
>
> I'm making access to the rate variables from VCMGenericEncoder, thread safe, by using a lock that's not associated with the encoder. There should be little to no contention there. While modifying VCMGenericEncoder, I noticed that a couple of member variables weren't needed, so I removed them.
>
> The reason for this change is that getStats is currently contending with the encoder when Bitrate() is called. On my machine, this means that getStats can take about 25-30ms instead of ~1ms.
>
> Also adding some documentation for other methods and a suggestion for how we could avoid contention between the encoder and the network thread.
>
> BUG=2822
> R=mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/43479004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45529004
Cr-Commit-Position: refs/heads/master@{#8640}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8640 4adac7df-926f-26a2-2b94-8c16560cd09d
This removes the none const pointer entry and SwapFrame.
Since frames delivered using VideoSendStream no longer use the external capture module, VideoSendStream will not get an incoming framerate callback. VideoSendStream now uses a rtc::RateTracker.
Also, the video engine must ensure that time stamps are always increasing.
With this, time stamps (ntp, render_time and rtp timestamps ) are checked and set in ViECapturer::OnIncomingCapturedFrame
BUG=1128
R=magjed@webrtc.org, mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46429004
Cr-Commit-Position: refs/heads/master@{#8633}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8633 4adac7df-926f-26a2-2b94-8c16560cd09d
Passed building isac_neon and modules_unittests on Android ARM64 and ARMv7.
Passed modules_unittests with following filters:
--gtest_filter=FiltersTest*
--gtest_filter=LpcMaskingModelTest*
--gtest_filter=TransformTest*
--gtest_filter=FilterBanksTest*
WebRtcIsacfix_CalculateResidualEnergyNeon is not enabled due to Issue 4224.
BUG=4002
R=andrew@webrtc.org, jridges@masque.com, kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39979004
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
Cr-Commit-Position: refs/heads/master@{#8632}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8632 4adac7df-926f-26a2-2b94-8c16560cd09d
These methods are called on the VideoSender's construction thread, which is the same thread as modifies the value of _encoder. It's therefore safe to not require a lock to access _encoder on this thread.
I'm making access to the rate variables from VCMGenericEncoder, thread safe, by using a lock that's not associated with the encoder. There should be little to no contention there. While modifying VCMGenericEncoder, I noticed that a couple of member variables weren't needed, so I removed them.
The reason for this change is that getStats is currently contending with the encoder when Bitrate() is called. On my machine, this means that getStats can take about 25-30ms instead of ~1ms.
Also adding some documentation for other methods and a suggestion for how we could avoid contention between the encoder and the network thread.
BUG=2822
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43479004
Cr-Commit-Position: refs/heads/master@{#8631}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8631 4adac7df-926f-26a2-2b94-8c16560cd09d
TextureVideoFrame is currently an empty shell that only provides a convenience constructor of I420VideoFrame with a texture buffer. This CL moves that constructor, and all unittests, of TextureVideoFrame into the base class. Then it's possible to completely remove TextureVideoFrame and all its files. Also, there is no point in having I420VideoFrame virtual anymore.
R=pbos@webrtc.org, perkj@webrtc.org, stefan@webrtc.org
TBR=mflodman
Review URL: https://webrtc-codereview.appspot.com/40229004
Cr-Commit-Position: refs/heads/master@{#8629}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8629 4adac7df-926f-26a2-2b94-8c16560cd09d
The known clients (GetStats and UMA histogram in Chrome) use at least 5 second aggregation window. There is no particular value in calculating the metrics more often.
The CL also includes a small refactoring moving a declaration inside an if statement.
BUG=2994
TEST=N/A
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40219004
Cr-Commit-Position: refs/heads/master@{#8619}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8619 4adac7df-926f-26a2-2b94-8c16560cd09d
It's possible to build Chrome on Windows with this patch now.
BUG=1128
> This is unfortunately causing build problems in Chrome on Windows.
>> Unify underlying frame buffer in I420VideoFrame and WebRtcVideoFrame
>>
>> Currently, I420VideoFrame uses three webrtc::Plane to store pixel data, and WebRtcVideoFrame uses WebRtcVideoFrame::FrameBuffer/webrtc::VideoFrame. The two subclasses WebRtcTextureVideoFrame and TextureVideoFrame use a NativeHandle to store pixel data, and there is also a class WebRtcVideoRenderFrame that wraps an I420VideoFrame.
>>
>> This CL replaces these classes with a new interface VideoFrameBuffer that provides the common functionality. This makes it possible to remove deep frame copies between cricket::VideoFrame and I420VideoFrame.
>>
>> Some additional minor changes are:
>> * Disallow creation of 0x0 texture frames.
>> * Remove the half-implemented ref count functions in I420VideoFrame.
>> * Remove the Alias functionality in WebRtcVideoFrame
>>
>> The final goal is to eliminate all frame copies, but to limit the scope of this CL, some planned changes are postponed to follow-up CL:s (see planned changes in https://webrtc-codereview.appspot.com/38879004, or https://docs.google.com/document/d/1bxoJZNmlo-Z9GnQwIaWpEG6hDlL_W-bzka8Zb_K2NbA/preview). Specifically, this CL:
>> * Keeps empty subclasses WebRtcTextureVideoFrame and TextureVideoFrame, and just delegates the construction to the superclass.
>> * Keeps the deep copies from cricket::VideoFrame to I420VideoFrame.
>>
>> BUG=1128
>> R=mflodman@webrtc.org, pbos@webrtc.org, perkj@webrtc.org, tommi@webrtc.org
>>
>> Review URL: https://webrtc-codereview.appspot.com/42469004R=pbos@webrtc.org
TBR=mflodman, pbos, perkj, tommi
Review URL: https://webrtc-codereview.appspot.com/45489004
Cr-Commit-Position: refs/heads/master@{#8616}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8616 4adac7df-926f-26a2-2b94-8c16560cd09d
Allow for setting different cpu_speed setting based on resolution, for non-simulcast.
Use the existing low resolution simulcast cpu_speed setting for the non-simulcast case.
No change to simulcast behavior, unless top/highest layer stream is also below CIF resolution,
(in which case all layers will use lower the cpu_speed setting =-4).
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37319004
Cr-Commit-Position: refs/heads/master@{#8603}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8603 4adac7df-926f-26a2-2b94-8c16560cd09d
This is unfortunately causing build problems in Chrome on Windows.
> Unify underlying frame buffer in I420VideoFrame and WebRtcVideoFrame
>
> Currently, I420VideoFrame uses three webrtc::Plane to store pixel data, and WebRtcVideoFrame uses WebRtcVideoFrame::FrameBuffer/webrtc::VideoFrame. The two subclasses WebRtcTextureVideoFrame and TextureVideoFrame use a NativeHandle to store pixel data, and there is also a class WebRtcVideoRenderFrame that wraps an I420VideoFrame.
>
> This CL replaces these classes with a new interface VideoFrameBuffer that provides the common functionality. This makes it possible to remove deep frame copies between cricket::VideoFrame and I420VideoFrame.
>
> Some additional minor changes are:
> * Disallow creation of 0x0 texture frames.
> * Remove the half-implemented ref count functions in I420VideoFrame.
> * Remove the Alias functionality in WebRtcVideoFrame
>
> The final goal is to eliminate all frame copies, but to limit the scope of this CL, some planned changes are postponed to follow-up CL:s (see planned changes in https://webrtc-codereview.appspot.com/38879004, or https://docs.google.com/document/d/1bxoJZNmlo-Z9GnQwIaWpEG6hDlL_W-bzka8Zb_K2NbA/preview). Specifically, this CL:
> * Keeps empty subclasses WebRtcTextureVideoFrame and TextureVideoFrame, and just delegates the construction to the superclass.
> * Keeps the deep copies from cricket::VideoFrame to I420VideoFrame.
>
> BUG=1128
> R=mflodman@webrtc.org, pbos@webrtc.org, perkj@webrtc.org, tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/42469004TBR=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42199005
Cr-Commit-Position: refs/heads/master@{#8599}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8599 4adac7df-926f-26a2-2b94-8c16560cd09d
Clang version changed 223108:230914
Details: e144d30..6fdb142/tools/clang/scripts/update.sh
Removes the OVERRIDE macro defined in:
* webrtc/base/common.h
* webrtc/typedefs.h
The majority of the source changes were done by running this in src/:
perl -0pi -e "s/virtual\s([^({;]*(\([^({;]*\)[^({;]*))(OVERRIDE|override)/\1override/sg" `find {talk,webrtc} -name "*.h" -o -name "*.cc*" -o -name "*.mm*"`
which converted all:
virtual Foo() OVERRIDE
functions to:
Foo() override
Then I manually edited:
* talk/media/webrtc/fakewebrtccommon.h
* webrtc/test/fake_common.h
Remaining uses of OVERRIDE was fixed by search+replace.
Manual edits were done to fix virtual destructors that were
overriding inherited ones.
Finally a build error related to the pure virtual definitions of
Read, Write and Rewind in common_types.h required a bit of
refactoring in:
* webrtc/common_types.cc
* webrtc/common_types.h
* webrtc/system_wrappers/interface/file_wrapper.h
* webrtc/system_wrappers/source/file_impl.cc
This roll should make it possible for us to finally re-enable deadlock
detection for TSan on the buildbots.
BUG=4106
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41069004
Cr-Commit-Position: refs/heads/master@{#8596}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8596 4adac7df-926f-26a2-2b94-8c16560cd09d
