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
The roll seems to cause leaks on our Linux Memcheck bot.
Added a suppression needed for Trusty in order to run
memcheck similar to the bot (that runs Precise).
Leave all the other source code edits from r8596 in place.
See also http://chromegw/i/client.webrtc/builders/Linux%20Memcheck/builds/3343TBR=pbos@webrtc.org
TESTED=Can no longer repro memcheck failure with this patch applied:
GYP_DEFINES="build_for_tool=memcheck" webrtc/build/gyp_webrtc
ninja -C out/Release libjingle_peerconnection_unittest
tools/valgrind-webrtc/webrtc_tests.sh --test libjingle_peerconnection_unittest --tool memcheck --target Release --build-dir out --gtest_filter=WebRtcSessionTest.TestIncorrectMLinesInLocalAnswer
Review URL: https://webrtc-codereview.appspot.com/47419004
Cr-Commit-Position: refs/heads/master@{#8612}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8612 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
Rename "AddValue" methods to AddXxx where Xxx is the type being added. Moving forward, we'll support those types natively without conversion to string.
Normalizing the extraction code to have fewer places that add the same stats and data driven additions to reports instead of multiple call sites.
BUG=2822
R=perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47369004
Cr-Commit-Position: refs/heads/master@{#8597}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8597 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
