This change connects currentAccelerateRate and currentPreemptiveRate
in webrtc::NetworkStatistics, through corresponding variables in
VoiceReceiverInfo, to googAccelerateRate and googPreemptiveExpandRate.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50179004
Cr-Commit-Position: refs/heads/master@{#9350}
This CL connects RTCConfiguration::audioJitterBufferFastMode in
PeerConnection.java, through libjingle, down to
NetEq::Config::enable_fast_accelerate in native WebRTC.
When enabled, it will allow NetEq to do faster time-compression when
the buffer level is very high.
BUG=4691
R=henrika@webrtc.org, mflodman@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/55479004
Cr-Commit-Position: refs/heads/master@{#9344}
BUG=4690
Changes:
1. In MediaEngineInterface changed CreateChannel() to CreateChannel(const AudioOptions&). Plan is to eventually remove Get/SetAudioOptions and the cousins SetDelayOffset and SetDevices.
2. In ChannelManager changed CreateVoiceChannel(...) to CreateVoiceChannel(..., const AudioOptions&).
3. In ChannelManager removed SetEngineAudioOptions, because it is not used and we want to eventually remove SetAudioOptions.
4. Updated MediaEngineInterface implementations and unit tests accordingly.
5. In WebRtcVoiceEngine changed access of Set/ClearOptionOverrides to protected. These are only used by WebRtcVoiceMediaChannel (now a friend). Plan is to rethink the logic behind option overrides.
6. Cosmetics: replaced NULL with nullptr in touched code
R=solenberg@google.com, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/56499004
Cr-Commit-Position: refs/heads/master@{#9330}
This fixes a bug where, if the VideoCapturer failed to start under certain circumstances, the capture manager would cause a callback saying that the capturer stopped even though it never started in the first place. A VERIFY check in VideoSource::SetState would then cause a crash since the state was set to kEnded when it was already in state kEnded (SetState only allows being called when the state changes).
I only noticed this bug while doing a mistake in a separate CL. Not sure how to reliably reproduce said bug on a working build, but I have previously had camera hardware issues where it couldn't start the camera which resulted in the SetState kEnded -> kEnded crash. Hopefully this will fix that.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51039004
Cr-Commit-Position: refs/heads/master@{#9259}
When a frame being stretched, the original rotation information is lost. This is to ensure it's carried over.
Also removed StretchToBuffer function as it's not called and dangerous.
BUG=4366
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51869004
Cr-Commit-Position: refs/heads/master@{#9224}
This implementation registers RTX-APT map inside RTP sender and receiver.
While it only generates SDP with RTX associated with VP8 to make it
compatible with previous Chrome versions.
Should add following changes after reaches stable,
* Use RTX-APT map for building and restoring RTP packets.
* Add RTX support for RED or VP9 in Video engine.
* Set RTX payload type for RED inside FecConfig in EndToEndTest.
BUG=4024
R=mflodman@webrtc.org, pbos@webrtc.org, pthatcher@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36889004
Cr-Commit-Position: refs/heads/master@{#9040}
1. Constructors, SetData(), and AppendData() now accept uint8_t*,
int8_t*, and char*. Previously, they accepted void*, meaning that
any kind of pointer was accepted. I think requiring an explicit
cast in cases where the input array isn't already of a byte-sized
type is a better compromise between convenience and safety.
2. data() can now return a uint8_t* instead of a char*, which seems
more appropriate for a byte array, and is harder to mix up with
zero-terminated C strings. data<int8_t>() is also available so
that callers that want that type instead won't have to cast, as
is data<char>() (which remains the default until all existing
callers have been fixed).
3. Constructors, SetData(), and AppendData() now accept arrays
natively, not just decayed to pointers. The advantage of this is
that callers don't have to pass the size separately.
4. There are new constructors that allow setting size and capacity
without initializing the array. Previously, this had to be done
separately after construction.
5. Instead of TransferTo(), Buffer now supports swap(), and move
construction and assignment, and has a Pass() method that works
just like std::move(). (The Pass method is modeled after
scoped_ptr::Pass().)
R=jmarusic@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42989004
Cr-Commit-Position: refs/heads/master@{#9033}
This is a major libyuv update (almost 200 revisions):
d204db6..32ad6e0
Relevant changes:
* src/third_party/libyuv: d204db6..32ad6e0
* src/third_party/nss: d1edb68..9506806
Details: 8af41b3..dcb0929/DEPS
Since bayer and Q420 format support have been removed from libyuv, all tests related to those format are removed.
Clang version was not updated in this roll.
R=kjellander@webrtc.org
TBR=tommi
Review URL: https://webrtc-codereview.appspot.com/48989004
Cr-Commit-Position: refs/heads/master@{#9008}
No need to include this header since the API is just taking a pointer to
it.
BUG=1092
TEST=./webrtc/build/gyp_webrtc && ninja -C out/Debug
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44059004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8928}
All RTP packets from sender side will carry the rotation info. (will file a bug to track this) On the receiving side, only packets with marker bit set will be examined.
Tests completed:
1. android standalone to android standalone
2. android standalone to chrome (with and without this change)
3. android on chrome
BUG=4145
R=glaznev@webrtc.org, mflodman@webrtc.org, perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47399004
Cr-Commit-Position: refs/heads/master@{#8905}
Removes 'googCaptureJitterMs' and 'googCaptureQueueDelayMsPerS' from
talk/. The overuse-detection method used is based on encoding time,
so these stats aren't useful enough to warrant having them showing up in
GetStats().
BUG=
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50469004
Cr-Commit-Position: refs/heads/master@{#8874}
If built-in Echo Cancellation is available on a device it is automatically enabled. The reason is that it in most cases performs better than the WebRTC software echo control for mobile. The drawback is that we can not develop, test and rollout the delay agnostic AEC (DA-AEC) on Android as for desktops.
This CL includes
- adding a media constraint to enable/disable DA-AEC.
- automatically turning on echo cancellation if DA-AEC is enabled.
- a fix in the AEC that enables delay estimation when DA-AEC is enabled, but delay metrics is disabled.
- sets the Config struct ReportedDelay, which controls DA-AEC internally in the AEC.
The test code to verify that it works in AppRTCDemo can be found here:
https://webrtc-codereview.appspot.com/50479004/
BUG=4472
TESTED=locally on N7, N6, Android One
R=glaznev@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48699004
Cr-Commit-Position: refs/heads/master@{#8861}
This CL deletes VideoAdapter::AdaptFrame and replaces the remaining calls with AdaptFrameResolution instead.
I do not expect this CL to fix the flaky VideoAdapterTests yet. I intend to replace FileVideoCapturer with a deterministic FakeVideoCapturer in a follow-up CL.
BUG=4317
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44769004
Cr-Commit-Position: refs/heads/master@{#8848}
And add a constructor for creating an uninitialized Buffer of a
specified size.
(I intend to follow up with more Buffer changes, but since it's rather
widely used, the rename is quite noisy and works better as a separate
CL.)
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48579004
Cr-Commit-Position: refs/heads/master@{#8841}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8841 4adac7df-926f-26a2-2b94-8c16560cd09d
This reverts r8683 and is a reland of r8682.
Reason for revert: The thread checker in Chromium that crashed has been fixed now.
BUG=1128
TBR=tommi,pbos,pthatcher
Review URL: https://webrtc-codereview.appspot.com/40319004
Cr-Commit-Position: refs/heads/master@{#8696}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8696 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
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
