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
I've kicked of a roll into Chromium with out the WebRtcVideoEngine2 change, to see if it was causing the roll problems, but re-landing in the meantime.
> Revert 8809 "Set WebRtcVideoEngine2 as the WebRtcMediaEngine."
> content_browsertests started failing around the time the change landed and rolls are failing now.
> I'm going to try rolling this back, start a roll, and then re-land.
>
> > Set WebRtcVideoEngine2 as the WebRtcMediaEngine.
> >
> > Removes the experiment launching WebRTC-NewVideoAPI. This field trial
> > has shown no major regressions on Chrome Canary/Dev that haven't been
> > addressed, so enabling it in time before feature freeze.
> >
> > BUG=1788
> > R=mflodman@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/44759004
>
> TBR=pbos@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/43889004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50459004
Cr-Commit-Position: refs/heads/master@{#8817}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8817 4adac7df-926f-26a2-2b94-8c16560cd09d
content_browsertests started failing around the time the change landed and rolls are failing now.
I'm going to try rolling this back, start a roll, and then re-land.
> Set WebRtcVideoEngine2 as the WebRtcMediaEngine.
>
> Removes the experiment launching WebRTC-NewVideoAPI. This field trial
> has shown no major regressions on Chrome Canary/Dev that haven't been
> addressed, so enabling it in time before feature freeze.
>
> BUG=1788
> R=mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/44759004TBR=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43889004
Cr-Commit-Position: refs/heads/master@{#8816}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8816 4adac7df-926f-26a2-2b94-8c16560cd09d
Instead of setting bitrates based on codec target settings (which may
have previously been capped by a codec max bitrate), fetch the last
bandwidth allocated for this channel. This fixes broken low start bitrates
due to QCIF being set as default codec in WebRtcVideoEngine2 which caps
the max bitrate to 200kbps.
BUG=1788
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43789004
Cr-Commit-Position: refs/heads/master@{#8780}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8780 4adac7df-926f-26a2-2b94-8c16560cd09d
Original cl description:
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
This cl was previously reverted in https://webrtc-codereview.appspot.com/46549004/.
Patchset 1 contains the original patch after rebase.
Patshet 2 fix webrtc_perf_tests reported in chromium:465306
Note that chromium:465287 is being fixed in https://webrtc-codereview.appspot.com/43829004/
BUG=1128
R=magjed@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47629004
Cr-Commit-Position: refs/heads/master@{#8776}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8776 4adac7df-926f-26a2-2b94-8c16560cd09d
This flag is passed to existing VieExternalCodec API (and others) to denote encoders that don't require/expect frames from the normal capture pipeline. This is the simplest way to allow camera->encoder texture support, until textures are supported through the normal camera pipeline and the lifetime issues are all figured out (I hear this is on the backlog, but not there yet).
Ideally, the flag would be on the encoder, but that doesn't work with SimulcastEncoderAdapter, since it doesn't create an encoder right away.
Note that this change only affects WebRtcVideoEngine (not WRVE2), since WRVE2 uses video_send_stream, and my hope is that by the time things have switched to WRVE2, textures will be supported with the normal camera pipeline and the dependency on internal sources can be thrown away.
BUG=
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42349004
Cr-Commit-Position: refs/heads/master@{#8769}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8769 4adac7df-926f-26a2-2b94-8c16560cd09d
As of r7849 the built-in AEC on devicing supporting it is enabled by default.
Unfortunately, the SW AEC (AECM) was not disabled, hence running on top of the built-in one. This is not necessary. In fact it reduce double talk performance significantly.
BUG=4431
TESTED=manually
R=henrika@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49419004
Cr-Commit-Position: refs/heads/master@{#8735}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8735 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
WebRtcTextureVideoFrame 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 WebRtcTextureVideoFrame into the base class. Then it's possible to completely remove WebRtcTextureVideoFrame and all its files.
BUG=1128
R=pbos@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48399004
Cr-Commit-Position: refs/heads/master@{#8638}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8638 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
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
