Reason for revert:
Reverting all CLs related to moving the eventlog, as they break Chromium tests.
Original issue's description:
> Fix for RtcEventLog ObjC interface
>
> This moves the RtcEventLog start/stop functions to PeerConnection on the objC interface.
>
> BUG=
> R=tkchin@webrtc.org
>
> Committed: c43bf56ef1TBR=tkchin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2110373002
Cr-Commit-Position: refs/heads/master@{#13338}
functionality and exposes the functionality using the
MediaConstraints.
The exposing of the feature through the MediaConstraints
was done similarly to what was done for the intelligibility
enhancer in the CL
https://codereview.webrtc.org/1952123003
This CL is dependent on the CL https://codereview.webrtc.org/2090583002/ which contains
the level control functionality.
NOTRY=true
BUG=webrtc:5920
Review-Url: https://codereview.webrtc.org/2095563002
Cr-Commit-Position: refs/heads/master@{#13336}
When the flag prune_turn_ports is set, When a high-priority turn port becomes available, it will prune low-priority ones. The pruned port will not be used for creating connections locally and its candidates will not be sent over to the remove side (unless they have been sent before being pruned).
This effectively reduces the number of TURN candidates and connections created by TURN ports.
BUG=
R=deadbeef@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2093623004 .
Cr-Commit-Position: refs/heads/master@{#13335}
The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).
The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
- PeerConnectionFactory.startInternalTracingCapture().
I've separated these two methods to make it more clear which of the
parameters controls which system.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2110853003
Cr-Commit-Position: refs/heads/master@{#13334}
Previously, we were starting a periodic timer when the local
description was set. The first connection may be created at any
time after this happens, so after creating the first connection, we
need to wait until that timer next fires before sending a ping.
Now we just start that timer (and send the first ping) immediately
after the first connection becomes pingable.
This CL also removes the "Connect" method. The only vestigal
effect of this method was to start the periodic timer, which is
now not needed since it happens automatically.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2099563004 .
Cr-Commit-Position: refs/heads/master@{#13331}
Test worked by creating a dummy data channel just to trigger the
SDP generation, then creating two data channels after negotiation.
However the dummy data channel is then racing with the "real" data
channel to get negotiated, so they could be signaled in the reverse
of the expected order.
Fixed this by simply waiting for the dummy data channel to be
signaled before creating the other data channels.
BUG=webrtc:3980
R=pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2112593002 .
Cr-Commit-Position: refs/heads/master@{#13329}
If the AutoDetectProxy timed out resolving one address, it was
attempting to use the same resolver to resolve the next address,
which would always result in an assertion. This happened recently
a couple times on the Windows DrMemory bot because of its slowness.
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2104203002 .
Cr-Commit-Position: refs/heads/master@{#13326}
In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
BUG=webrtc:4741,webrtc:5603,chromium:609749
R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1748403002 .
Cr-Commit-Position: refs/heads/master@{#13321}
This really only happens on the memcheck bot. But the issue is that
the render thread may be started before the timer is started on
the main thread, which incorrectly attaches the timer to the render
thread. Then a thread check assertion occurs when the timer is
stopped on the main thread.
Simply starting the timer before starting the render thread fixes this.
BUG=webrtc:6062
TBR=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2105013002 .
Cr-Commit-Position: refs/heads/master@{#13317}
Also move getDeviceNames to a more appropriate location in the file.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2105813002
Cr-Commit-Position: refs/heads/master@{#13312}
The "should I simulate EWOULDBLOCK?" determination now happens
solely in P2PTransportChannel. This also fixes a bug where the
"last packet id" was set even if no packet was sent.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2099783002 .
Cr-Commit-Position: refs/heads/master@{#13307}
Relanding again after fixing issue with RTC_DCHECKs.
This CL eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.
It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2046173002 .
Cr-Commit-Position: refs/heads/master@{#13305}
The fake clock has a few advantages:
1. It lets use verify that operations take the expected number of
round trips.
2. It makes the tests faster by letting us remove the equivalent
of "Sleep(500)" all over the tests.
3. It makes the tests less flaky, because sometimes sleeping for
500ms or waiting for 1s is not enough.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2097793003 .
Cr-Commit-Position: refs/heads/master@{#13304}
Was thought to be only flaky on Mac, but just failed on Win SyzyASan.
So, disabling until flakiness is fixed.
BUG=webrtc:4332
TBR=pbos@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2104583002
Cr-Commit-Position: refs/heads/master@{#13303}
This test currently takes 288 seconds to fail if output values are
wrong; there's no point to print the failure hundreds of times.
This change will exit the test early.
R=henrika@webrtc.org
BUG=623538
NOTRY=true
Review-Url: https://codereview.webrtc.org/2097363002
Cr-Commit-Position: refs/heads/master@{#13295}
The plan is that the CameraEnumerationAndroid will in the future have
method called getEnumerator that will return an enumerator that can be
used to create CameraVideoCapturer objects. It will return
Camera2Enumerator if it is supported or else Camera1Enumerator. Some
apps want to capture to byte buffers which is no longer supported in the
camera2 version of CameraVideoCapturer. Camera1Enumerator constructed
with false parameter as captureToTexture will be returned to these apps.
BUG=webrtc:5519
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/2071213003 .
Cr-Commit-Position: refs/heads/master@{#13294}
Reason for revert:
Broke video sending for iOS AppRTCDemo. To repro, run iOS AppRTCDemo in Release in loopback mode. The revision prior to this change worked.
Original issue's description:
> Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.
>
> This eliminates the need for the extra layer of indirection provided by
> mediastreamprovider.h. It will thus make it easier to implement new
> functionality in RtpSender/RtpReceiver.
>
> It also brings us one step closer to the end goal of combining "senders"
> and "send streams". Currently the sender still needs to go through the
> BaseChannel and MediaChannel, using an SSRC as a key.
>
> R=pthatcher@webrtc.org
>
> Committed: 2d5491783aTBR=pthatcher@webrtc.org,deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2092273003
Cr-Commit-Position: refs/heads/master@{#13289}
