This will allow Chromium's build files to be updated, so that when the
real RtpSender CL is submitted, it doesn't break the FYI bots.
Review URL: https://codereview.webrtc.org/1364813004
Cr-Commit-Position: refs/heads/master@{#10065}
Reason for revert:
Broke FYI bots because SetConfiguration is pure virtual and MockPeerConnectionImpl doesn't implement it. Need to reland with SetConfiguration not pure virtual.
Original issue's description:
> Adding PeerConnectionInterface::SetConfiguration method.
>
> Also updated the JNI and Objective-C bindings. Later, will have a CL to
> remove UpdateIce, which this method effectively replaces.
>
> BUG=webrtc:4945
>
> Committed: https://crrev.com/70702afbcb8418fe93747e7ed63bcbf5e56b90e9
> Cr-Commit-Position: refs/heads/master@{#10040}
TBR=guoweis@webrtc.org,pthatcher@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4945
Review URL: https://codereview.webrtc.org/1361263002
Cr-Commit-Position: refs/heads/master@{#10041}
Also updated the JNI and Objective-C bindings. Later, will have a CL to
remove UpdateIce, which this method effectively replaces.
BUG=webrtc:4945
Review URL: https://codereview.webrtc.org/1317353005
Cr-Commit-Position: refs/heads/master@{#10040}
Reason for revert:
This CL just landed: https://codereview.chromium.org/1323243006/
Which fixes the FYI bots for the original CL, and breaks them for this revert.
Original issue's description:
> Revert of TransportController refactoring. (patchset #6 id:100001 of https://codereview.webrtc.org/1350523003/ )
>
> Reason for revert:
> This CL causes problems with the WebRTC-in-Chromium FYI bots. Presumably it needs to be done in several steps, where removed files are emptied instead of removed in the first step.
>
> Original issue's description:
> > TransportController refactoring.
> >
> > Getting rid of TransportProxy, and in its place adding a
> > TransportController class which will facilitate access to and manage
> > the lifetimes of Transports. These Transports will now be accessed
> > solely from the worker thread, simplifying their implementation.
> >
> > This refactoring also pulls Transport-related code out of BaseSession.
> > Which means that BaseChannels will now rely on the TransportController
> > interface to create channels, rather than BaseSession.
> >
> > Committed: https://crrev.com/47ee2f3b9f33e8938948c482c921d4e13a3acd83
> > Cr-Commit-Position: refs/heads/master@{#10022}
>
> TBR=pthatcher@webrtc.org,deadbeef@webrtc.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://crrev.com/a81a42f584baa0d93a4b93da9632415e8922450c
> Cr-Commit-Position: refs/heads/master@{#10024}
TBR=pthatcher@webrtc.org,torbjorng@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1361773005
Cr-Commit-Position: refs/heads/master@{#10036}
Removes ShouldIgnoreTrace from WebRtcVoiceEngine and removes the spammy
log instances instead. Also removes trace-style logging from getters
(::GetLocalSSRC() for instance would print what SSRC it got, spamming
the log).
BUG=
R=henrika@webrtc.org
Review URL: https://codereview.webrtc.org/1347353004 .
Cr-Commit-Position: refs/heads/master@{#10028}
This CL makes the following changes:
* Instead of creating a new thread per startCapture()/stopCapture() cycle, VideoCapturerAndroid has a single thread that is initialized in the constructor and kept during the lifetime of the instance. This is more convenient because then it is always possible to post runnables without if-checks. This way, a lot of synchronize statements can be removed. Also, when the camera thread is preserved after stopCapture() it is possible to post late returnBuffer() calls to the correct thread.
* FramePool now enforces single thread use and returnBuffer() calls are posted to the camera thread. This is important because the camera should only be used from one thread, and we call camera.addCallbackBuffer() in returnBuffer().
* switchCamera() no longer returns false on failure, but instead signals the result via the callback.
* Update the test testCaptureAndAsyncRender() - it's not a valid use case to have outstanding frames when calling PeerConnectionFactory.dispose(). Instead, the renderer implementations should have release() functions that block until all frames are returned. The release() functions need to be called in the correct order with PeerConnectionFactory.dispose() last.
BUG=webrtc:4909
R=hbos@webrtc.org, perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1350863002 .
Cr-Commit-Position: refs/heads/master@{#10025}
Reason for revert:
This CL causes problems with the WebRTC-in-Chromium FYI bots. Presumably it needs to be done in several steps, where removed files are emptied instead of removed in the first step.
Original issue's description:
> TransportController refactoring.
>
> Getting rid of TransportProxy, and in its place adding a
> TransportController class which will facilitate access to and manage
> the lifetimes of Transports. These Transports will now be accessed
> solely from the worker thread, simplifying their implementation.
>
> This refactoring also pulls Transport-related code out of BaseSession.
> Which means that BaseChannels will now rely on the TransportController
> interface to create channels, rather than BaseSession.
>
> Committed: https://crrev.com/47ee2f3b9f33e8938948c482c921d4e13a3acd83
> Cr-Commit-Position: refs/heads/master@{#10022}
TBR=pthatcher@webrtc.org,deadbeef@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1358413003
Cr-Commit-Position: refs/heads/master@{#10024}
Getting rid of TransportProxy, and in its place adding a
TransportController class which will facilitate access to and manage
the lifetimes of Transports. These Transports will now be accessed
solely from the worker thread, simplifying their implementation.
This refactoring also pulls Transport-related code out of BaseSession.
Which means that BaseChannels will now rely on the TransportController
interface to create channels, rather than BaseSession.
Review URL: https://codereview.webrtc.org/1350523003
Cr-Commit-Position: refs/heads/master@{#10022}
Reason for revert:
Broke the Windows build:
[226/365] LINK_EMBED cc_perftests.exe
FAILED: ninja -t msvc -e environment.x86 -- E:\b\build\goma/gomacc "E:\b\depot_tools\win_toolchain\vs2013_files\VC\bin\amd64_x86\cl.exe" /nologo /showIncludes /FC @obj\remoting\protocol\remoting_unittests.channel_socket_adapter_unittest.obj.rsp /c ..\..\remoting\protocol\channel_socket_adapter_unittest.cc /Foobj\remoting\protocol\remoting_unittests.channel_socket_adapter_unittest.obj /Fdobj\remoting\remoting_unittests.cc.pdb
e:\b\build\slave\win\build\src\remoting\protocol\channel_socket_adapter_unittest.cc(36) : error C3861: 'set_readable': identifier not found
ninja: build stopped: subcommand failed.
Original issue's description:
> Replace readable with receiving where receiving means receiving anything (stun ping, response or data packet).
> If a connection does not receive for 30 seconds, it will be deleted.
> BUG=
>
> Committed: https://crrev.com/ae16f8547d3b447f62f6660f13688585c6c3de15
> Cr-Commit-Position: refs/heads/master@{#10001}
TBR=pthatcher@webrtc.org,honghaiz@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1356103002
Cr-Commit-Position: refs/heads/master@{#10002}
If a connection does not receive for 30 seconds, it will be deleted.
BUG=
Review URL: https://codereview.webrtc.org/1351673003
Cr-Commit-Position: refs/heads/master@{#10001}
The Android camera api requires a surface to be set in order work. In https://codereview.webrtc.org/1354683004/ this surfaceTexture was removed as a member but it turns out that can lead to camera freezes when the device is rotated. This cl re-adds the surface as a member.
BUG= webrtc:5021, webrtc:5003
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1349433003 .
Cr-Commit-Position: refs/heads/master@{#9999}
This change the PeerConnectionTest.doTest wait for at least one ice candidate and also make sure the list of candidates in gotIceCandidates is synchronized.
BUG=webrtc:5010
Review URL: https://codereview.webrtc.org/1354913002
Cr-Commit-Position: refs/heads/master@{#9997}
Video capture for android is now implemented in talk/app/webrtc/androidvideocapturer.h
BUG=webrtc:4475
Review URL: https://codereview.webrtc.org/1347083003
Cr-Commit-Position: refs/heads/master@{#9995}
Getting rid of TransportProxy, and in its place adding a
TransportController class which will facilitate access to and manage
the lifetimes of Transports. These Transports will now be accessed
solely from the worker thread, simplifying their implementation.
This refactoring also pulls Transport-related code out of BaseSession.
Which means that BaseChannels will now rely on the TransportController
interface to create channels, rather than BaseSession.
This CL also adds some unit tests, and does some renaming.
For example, from "CandidateReady" to "CandidateGathered".
Review URL: https://codereview.webrtc.org/1246913005
Cr-Commit-Position: refs/heads/master@{#9993}
To make this possible padding only packets will have the same timestamp
as the previously sent media packet, as long as RTX is not enabled. This
has the side effect that if we send only padding for a long time without
sending media, a receive-side jitter buffer could potentially overflow.
In practice this shouldn't be an issue, partly because RTX is recommended and
used by default, but also because padding typically is terminated before being
received by a client. It is also not an issue for bandwidth estimation as long
as abs-send-time is used instead of toffset.
BUG=chromium:425925
R=mflodman@webrtc.org, sprang@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1327933003 .
Cr-Commit-Position: refs/heads/master@{#9984}
Starts by removing channel/engine id from ViEChannel which propagates
down to the RTP/RTCP module as well as the transport class.
IncomingVideoStream::RenderFrame() is untouched for now but receives a
fake id instead of the previous channel id. Added a TODO to remove it
later but the RenderFrame call is implemented in a lot of
platform-dependent files and should probably remove the "manager" aspect
of renderers, so preferring to do it separately
BUG=webrtc:1695
R=henrika@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1335353005 .
Cr-Commit-Position: refs/heads/master@{#9978}
WebRtcPassthroughRender has been dead since webrtcvideoengine.cc was
removed, FakeExternalTransport has probably been unused for a long time.
BUG=webrtc:1695
R=henrika@webrtc.org
Review URL: https://codereview.webrtc.org/1343393003 .
Cr-Commit-Position: refs/heads/master@{#9968}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
Part of work removing dependency on Chromium's base.
Only adds "= delete". From https://codereview.chromium.org/1151443003 :
"This will guarantee the error to be at compile time, and not rely on the call visibility (private)."
In consequence of that change, fixed an illegal copy and removed a bunch of unused variables.
Depends on https://codereview.webrtc.org/1345433002/
BUG=chromium:468375
(in particular comment #37)
NOTRY=true
Review URL: https://codereview.webrtc.org/1342543004
Cr-Commit-Position: refs/heads/master@{#9954}
