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}
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
Review URL: https://codereview.webrtc.org/2046173002 .
Cr-Commit-Position: refs/heads/master@{#13287}
Reason for revert:
Broke peerconnection_unittest somehow, due to introduction of thread check. Will fix and reland.
Original issue's description:
> 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: https://crrev.com/bc5831999d3354509d75357b659b4bb8e39f8a6c
> Cr-Commit-Position: refs/heads/master@{#13285}
TBR=pthatcher@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/2099843003
Cr-Commit-Position: refs/heads/master@{#13286}
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
Review URL: https://codereview.webrtc.org/2046173002 .
Cr-Commit-Position: refs/heads/master@{#13285}
Reason for revert:
Didn't intend to land yet. Chromium CL still needed.
Original issue's description:
> Add virtual Initialize methods to PortAllocator and NetworkManager.
>
> This will allow PeerConnection to handle hopping to the right thread
> and doing thread-specific initialization for the PortAllocator.
> This eliminates a required thread-hop for whatever is passing the
> PortAllocator into CreatePeerConnection.
>
> BUG=617648
> R=pthatcher@webrtc.org, skvlad@webrtc.org
>
> Committed: https://crrev.com/a6bdb0990a659ff9e7c4374f5033a6bcc4fbfb21
> Cr-Commit-Position: refs/heads/master@{#13283}
TBR=pthatcher@webrtc.org,skvlad@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=617648
Review-Url: https://codereview.webrtc.org/2092023004
Cr-Commit-Position: refs/heads/master@{#13284}
This will allow PeerConnection to handle hopping to the right thread
and doing thread-specific initialization for the PortAllocator.
This eliminates a required thread-hop for whatever is passing the
PortAllocator into CreatePeerConnection.
BUG=617648
R=pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2097653002 .
Cr-Commit-Position: refs/heads/master@{#13283}
Reason for revert:
It turns out this revert was not necessary because the connection-state mapping for turn-turn connections was not done in connection.
Original issue's description:
> Revert of Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://… (patchset #5 id:120001 of https://codereview.webrtc.org/2041593002/ )
>
> Reason for revert:
> ReadyToSendMedia did not consider the new presumed_writable state.
>
> Original issue's description:
> > Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://codereview.webrtc.org/2000063003/ )"
> >
> > This reverts commit 72d41aa6da94dacb8a8464d1abd4ca7d1afffc65.
> >
> > New change made:
> > Do not reset the BWE when the new network route is not ready to send media.
> >
> > BUG=
> > R=pthatcher@webrtc.org, stefan@webrtc.org
> >
TBR=pthatcher@webrtc.org,stefan@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2094863003
Cr-Commit-Position: refs/heads/master@{#13282}
When Windows is switching display mode, DirectX based capturer may not be able
to create a new IDXGIOutputDuplication instance, which is expected. So it should
return a temporary error instead of a permanent error.
BUG=
Review-Url: https://codereview.webrtc.org/2092543003
Cr-Commit-Position: refs/heads/master@{#13279}
