Reason for revert:
Still cause break on mac. reverting it again.
Original issue's description:
> Reland of Add experiment on weak ping delay during call set up time (patchset #1 id:1 of https://codereview.webrtc.org/1423443002/ )
>
> Reason for revert:
> This should be safe to land now.
>
> Original issue's description:
> > Revert of Add experiment on weak ping delay during call set up time (patchset #4 id:60001 of https://codereview.webrtc.org/1411883002/ )
> >
> > Reason for revert:
> > guoweis - Here's the target that's failing:
> > https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/libjingle_nacl.gyp&l=17
> >
> > This has unfortunately been causing problems repeatedly for us since libjingle_nacl is maintained separately from libjingle (I don't know the history).
> >
> > The way this works for Chrome in general is that the FindFullName method is implemented in init_webrtc.cc in the overrides folder in Chrome and that hooks WebRTC up with Chrome's implementation. I'm not sure if that's the right thing to do for nacl, how webrtc is initialized there etc. I'll ping the nacl team for some help too offline and include you. Reverting this change for now.
> >
> > Original issue's description:
> > > Add experiment on weak ping delay during call set up time
> > >
> > > BUG=
> > > R=pthatcher@webrtc.org
> > >
> > > Committed: https://crrev.com/3bf69b15f4c0c0ca4ab17c237084684a37bb8279
> > > Cr-Commit-Position: refs/heads/master@{#10343}
> >
> > TBR=pthatcher@webrtc.org,juberti@webrtc.org,guoweis@webrtc.org
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=
> >
> > Committed: https://crrev.com/a01d44022355796d4fd86d00aae6d3263573b6f1
> > Cr-Commit-Position: refs/heads/master@{#10350}
>
> TBR=pthatcher@webrtc.org,juberti@webrtc.org,tommi@webrtc.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/e26ce1b7a4644942b239ed788a737200762db3b3
> Cr-Commit-Position: refs/heads/master@{#10379}
TBR=pthatcher@webrtc.org,juberti@webrtc.org,tommi@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1413843003
Cr-Commit-Position: refs/heads/master@{#10380}
Reason for revert:
This should be safe to land now.
Original issue's description:
> Revert of Add experiment on weak ping delay during call set up time (patchset #4 id:60001 of https://codereview.webrtc.org/1411883002/ )
>
> Reason for revert:
> guoweis - Here's the target that's failing:
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/libjingle_nacl.gyp&l=17
>
> This has unfortunately been causing problems repeatedly for us since libjingle_nacl is maintained separately from libjingle (I don't know the history).
>
> The way this works for Chrome in general is that the FindFullName method is implemented in init_webrtc.cc in the overrides folder in Chrome and that hooks WebRTC up with Chrome's implementation. I'm not sure if that's the right thing to do for nacl, how webrtc is initialized there etc. I'll ping the nacl team for some help too offline and include you. Reverting this change for now.
>
> Original issue's description:
> > Add experiment on weak ping delay during call set up time
> >
> > BUG=
> > R=pthatcher@webrtc.org
> >
> > Committed: https://crrev.com/3bf69b15f4c0c0ca4ab17c237084684a37bb8279
> > Cr-Commit-Position: refs/heads/master@{#10343}
>
> TBR=pthatcher@webrtc.org,juberti@webrtc.org,guoweis@webrtc.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/a01d44022355796d4fd86d00aae6d3263573b6f1
> Cr-Commit-Position: refs/heads/master@{#10350}
TBR=pthatcher@webrtc.org,juberti@webrtc.org,tommi@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1406153005
Cr-Commit-Position: refs/heads/master@{#10379}
The purpose with this change is to support older API levels by replacing EGL14 (API lvl 17) with EGL10 (API lvl 1). The main purpose is to lower API lvl requirement for SurfaceViewRenderer from API lvl 17 to API lvl 15. Also, camera texture capture will work on API lvl < 17 (and texture encode/decode in MediaCodec, but we don't use MediaCodec below API lvl 18?).
GLSurfaceView/VideoRendererGui is already using EGL10.
EGL 1.1 - 1.4 added new functionality, but won't affect performance. We don't need the functionality, so there should be no reason to not use EGL 1.0.
I have profiled AppRTCDemo with Qualcomm Trepn Profiler on a Nexus 5 and Nexus 6 and couldn't see any difference.
Specifically, this CL:
* Update EglBase to use EGL10 instead of EGL14.
* Update imports from EGL14 to EGL10 in a lot of files (plus changing import order in some cases).
* Update VideoCapturerAndroid to always support texture capture.
Review URL: https://codereview.webrtc.org/1396013004
Cr-Commit-Position: refs/heads/master@{#10378}
By default, we'll now offer to receive if already receiving
(meaning that the last remote description contained a track).
Also, m-lines that are neither receiving nor sending are now correctly
marked "inactive".
Also moved some logic relating to default tracks out of webrtcsdp.cc,
such that now the direction seen by upper layers will always be
consistent with the consumed/produced SDP.
BUG=528089
Review URL: https://codereview.webrtc.org/1406803004
Cr-Commit-Position: refs/heads/master@{#10376}
Before this change, UpdateEstimate would repeatedly decrease bitrate
even though there's no fresh corresponding RTCP loss report, triggering
multiple reactions to a single indication of high packet loss.
BUG=webrtc:5101
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1417723005
Cr-Commit-Position: refs/heads/master@{#10374}
Like video_decoder.cc, a call to Encode that returns
WEBRTC_VIDEO_CODEC_FALLBACK_SOFTWARE will trigger an attempted fallback
to a built-in software encoder. Initialization information, along with
any rate and channel parameter info, will be replayed on the software
encoder and then the frame (that cause the fallback) will be immediately
replayed for the software encoder.
Also modified the existing behavior to Release() the "real" encoder even
if a fallback encoder exists. That seems like the correct behavior.
BUG=webrtc:2920
Review URL: https://codereview.webrtc.org/1328863002
Cr-Commit-Position: refs/heads/master@{#10368}
Xvfb is needed for the screen capture tests in modules_unittests,
which also brings in xdisplaycheck used by testing/xvfb.py.
libjingle_media_unittest was missing a resource video in the .isolate
file.
BUG=chromium:497757
R=stip@chromium.org
Review URL: https://codereview.webrtc.org/1415603005 .
Cr-Commit-Position: refs/heads/master@{#10365}
We don't allow more than one retransmission within one RTT, but the RTT
estimate might be off. Reasonably, the remote end will not send a NACK
until the packet after has been received - so always resend on first
request.
Review URL: https://codereview.webrtc.org/1414563003
Cr-Commit-Position: refs/heads/master@{#10362}
Reports show that we see full echo from the OnePlus 2 device.
Disabling hardware effects and revert to WebRTC-based
components instead as a test to see if it helps.
R=tommi@webrtc.org
TBR=tommi
BUG=b/25096456
Review URL: https://codereview.webrtc.org/1417093002 .
Cr-Commit-Position: refs/heads/master@{#10357}
This patch also also ensures that audio is restored after an incoming
GSM call.
BUG=webrtc:5058, webrtc:5012
TEST=Manual tests using modified AppRTCDemo and three different BT headsets
Review URL: https://codereview.webrtc.org/1401963002
Cr-Commit-Position: refs/heads/master@{#10354}
It's a simple std::experimental::optional-wannabe. For simplicity and
portability, it still secretly contains a (default-constructed) T when
it's supposedly empty. This restriction is fine for simple types.
One important application is for the return type of functions. For
example, a function which either returns a size_t or fails can return
rtc::Maybe<size_t>.
BUG=webrtc:5028
R=andrew@webrtc.org, mgraczyk@chromium.org
Review URL: https://codereview.webrtc.org/1413763003 .
Cr-Commit-Position: refs/heads/master@{#10353}
Reason for revert:
guoweis - Here's the target that's failing:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/libjingle_nacl.gyp&l=17
This has unfortunately been causing problems repeatedly for us since libjingle_nacl is maintained separately from libjingle (I don't know the history).
The way this works for Chrome in general is that the FindFullName method is implemented in init_webrtc.cc in the overrides folder in Chrome and that hooks WebRTC up with Chrome's implementation. I'm not sure if that's the right thing to do for nacl, how webrtc is initialized there etc. I'll ping the nacl team for some help too offline and include you. Reverting this change for now.
Original issue's description:
> Add experiment on weak ping delay during call set up time
>
> BUG=
> R=pthatcher@webrtc.org
>
> Committed: https://crrev.com/3bf69b15f4c0c0ca4ab17c237084684a37bb8279
> Cr-Commit-Position: refs/heads/master@{#10343}
TBR=pthatcher@webrtc.org,juberti@webrtc.org,guoweis@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1423443002
Cr-Commit-Position: refs/heads/master@{#10350}
Added a test that verifies that waiting for a condition variable
actually waits for a non-zero time.
This used to fail due to a TSAN / CLANG bug, but this failure
is supposed to have been fixed.
This was originally https://webrtc-codereview.appspot.com/2145004
BUG=2259
Review URL: https://codereview.webrtc.org/1416873002
Cr-Commit-Position: refs/heads/master@{#10341}
Some toolchains (in this case referring to a g++ 4.9, or "arm-linux-
androideabi-g++ (GCC) 4.9 20140827 (prerelease)" according to my
--version, from the Android NDK r10e-rc4 and potentially with custom
patches; others may be affected as well) fail to prove that myVec in
WebRtcIsac_CorrelateInterVec is never used uninitialized. This is likely
due to the compiler thinking the assignment in line 468 might not
happen. Changing the loop condition in line 466 to rowCntr <
SOME_CONSTANT also helps, suggesting that the compiler can't infer that
there are only 2 values interVecDim can have at that point, and neither
of them are 0. Of course, this is not an acceptable fix, as it changes
behaviour.
This seems to be a compiler bug, or at least an issue with its
heuristics. However, we can't really change toolchains at the moment,
and ultimately this change improves support for certain older compilers.
BUG=
Review URL: https://codereview.webrtc.org/1406423004
Cr-Commit-Position: refs/heads/master@{#10337}
Two concurrently running decoders will trigger data races on cpu_info_
which is lazily initialized on reading TestCpuFlag without proper
atomics.
BUG=libyuv:508
R=kjellander@webrtc.org
TEST=Running EndToEndTest.SendsAndReceivesMultipleStreams under TSan.
Review URL: https://codereview.webrtc.org/1414093003 .
Cr-Commit-Position: refs/heads/master@{#10335}
- "WebRTC.Video.BandwidthLimitedResolutionInPercent"
If the frame is bandwidth limited, the average number of disabled resolutions is logged:
- "WebRTC.Video.BandwidthLimitedResolutionsDisabled"
BUG=
Review URL: https://codereview.webrtc.org/1311533012
Cr-Commit-Position: refs/heads/master@{#10333}
Reason for revert:
Reverting to see of this resolves build bot failures (Nexus 7.2, especially debug) which now seems to sometimes fail to start tests altogether.
Original issue's description:
> Add screenshare perf tests with lossy links
>
> BUG=
>
> Committed: https://crrev.com/4af0f1a098bc908cfe825981b825687673d5134a
> Cr-Commit-Position: refs/heads/master@{#10290}
TBR=pbos@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1415603002
Cr-Commit-Position: refs/heads/master@{#10322}
- "WebRTC.Video.QualityLimitedResolutionInPercent"
and if a frame is downscaled, the average number of times the frame is downscaled:
- "WebRTC.Video.QualityLimitedResolutionDownscales"
BUG=
Review URL: https://codereview.webrtc.org/1325153009
Cr-Commit-Position: refs/heads/master@{#10319}
This CL changes as little as possible and I'll follow up later with
ownership of the other members in ChannelGroup.
The next step is to remove the id used for channels.
BUG=webrtc:5079
Review URL: https://codereview.webrtc.org/1411723002
Cr-Commit-Position: refs/heads/master@{#10318}
External consumers may have a dependency on the old name, so this will give them the opportunity to switch over.
BUG=
Review URL: https://codereview.webrtc.org/1414543002
Cr-Commit-Position: refs/heads/master@{#10310}
Sounds better according to a MUSHRA listening test.
The computational complexity is unaffected.
An empirically estimated gain was added to compensate for the attenuation introduced by the algorithm.
There are some TODOs, which I will address in follow up CLs.
It was tested in Hangouts without headphones and highest volume, to make sure it doesn't affect the AEC.
Review URL: https://codereview.webrtc.org/1378973003
Cr-Commit-Position: refs/heads/master@{#10308}
AudioSendStream will be replacing the send side of VoiceEngine channels and associated APIs. Hence, they will be used transform recorded audio into RTP/RTCP packets that can be transmitted to another party, according to given parameters.
BUG=webrtc:4690
Review URL: https://codereview.webrtc.org/1397123003
Cr-Commit-Position: refs/heads/master@{#10307}
This patch removes set_fail_redirect()/fail_redirect() method accessors
from HttpClient class and converts their usage to
set_redirection_action/redirection_action where appropriate.
BUG=None
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1396683005
Cr-Commit-Position: refs/heads/master@{#10304}
Time to keep old events in buffer is now changeable at runtime.
Added unit test for removing old events from buffer.
Review URL: https://codereview.webrtc.org/1303713002
Cr-Commit-Position: refs/heads/master@{#10302}
This removes the TRFC rate control which does not introduce any help in the
computation of the sending rate.
BUG=5083
Review URL: https://codereview.webrtc.org/1383813003
Cr-Commit-Position: refs/heads/master@{#10299}
This is the first CL to get ready for adapting audio bitrate based on
BWE. I've kept this CL as small as possible and had to add a few getters
to ChannelManager. The next CL will do the same for receive ViEChannels.
The getters are a bit uggly, but is an in-between-state. Let's discuss
future ownership of the different modules and what do do with
ChannelGroup.
BUG=5079
Review URL: https://codereview.webrtc.org/1394243006
Cr-Commit-Position: refs/heads/master@{#10298}
