* Remove the peerconnection_server target from peerconnection.gyp since we have it in libjingle.gyp.
* Add enabled_libjingle_device_manager in supplement.gypi to add devicemanger to stand alone build.
* Add link settings to base.gyp which is needed by the new changes in peerconnection_client.
Note: Resolving hostname function has some problem on Windows in this revision.
So with this revision the peerconnection client can only take ip address directly as
the server address on Windows.
Review URL: https://webrtc-codereview.appspot.com/753008
git-svn-id: http://webrtc.googlecode.com/svn/trunk@2689 4adac7df-926f-26a2-2b94-8c16560cd09d
Hijacking the gyp inside_chromium_build finally came back to bite us.
Chrome started using it to control the path to the gold linker, which
broke our build. This change removes use of inside_chromium_build from
WebRTC.
If peerconnection rolls past this point, libjingle.gyp will need to be updated.
BUG=
TEST=build on Linux, Mac, Win
Review URL: https://webrtc-codereview.appspot.com/493007
git-svn-id: http://webrtc.googlecode.com/svn/trunk@2038 4adac7df-926f-26a2-2b94-8c16560cd09d
The purpose for the xvfb mode is to be able to run tests on the windowless environment on the Chromebot. Given the right input video, we can then write a relatively simple algorithm to analyze the screenshots and thereby conclude that video is playing.
BUG=
TEST=
Review URL: https://webrtc-codereview.appspot.com/447004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@1890 4adac7df-926f-26a2-2b94-8c16560cd09d
* Signaling messages are added to the log with a '+' / '-' sign to expand/collapse the message. This makes the log easier to read and each message can be read separate from the others.
* Loopback enabled by default since that's the most common use case.
* Wrapped some lines at 80 for easier future diffing.
Review URL: http://webrtc-codereview.appspot.com/214001
git-svn-id: http://webrtc.googlecode.com/svn/trunk@711 4adac7df-926f-26a2-2b94-8c16560cd09d
Links but does not work since the new peerconnection is under development.
I would like to commit a version with as few changes as possible to the old peerconnection_client but using the new PeerConnection API.
BUG=
TEST=
Review URL: http://webrtc-codereview.appspot.com/183003
git-svn-id: http://webrtc.googlecode.com/svn/trunk@677 4adac7df-926f-26a2-2b94-8c16560cd09d
* Remove (most of) local libjingle mods. Only webrtcvideoengine and webrtcvoiceengine are left now, because the refcounted module has not yet been released to libjingle, so I can't submit the changes to libjingle at the moment.
* Update the peerconnection client sample app.
Review URL: http://webrtc-codereview.appspot.com/151004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@625 4adac7df-926f-26a2-2b94-8c16560cd09d
* Fixes bug where remote video wasn't renderered.
* Update the Conductor class in accordance to the latest changes in the API.
We now process the stream add/remove callbacks asynchronously.
* When a remote peer connects to us, we now call AddStream for our local streams
to share with the peer if we haven't already done so. To do that, we maintain
a set of streams we have already shared.
BUG=11
Review URL: http://webrtc-codereview.appspot.com/131011
git-svn-id: http://webrtc.googlecode.com/svn/trunk@506 4adac7df-926f-26a2-2b94-8c16560cd09d
Removed OnLocalStreamInitialized callback from the PeerConnection callback list. After adding OnAddStream trigger at the originator this callback was redundant. Also other modification is to provide same stream label in OnAddStream callback at the originator which provided in AddStream API.
Review URL: http://webrtc-codereview.appspot.com/138002
git-svn-id: http://webrtc.googlecode.com/svn/trunk@490 4adac7df-926f-26a2-2b94-8c16560cd09d
I made several updates to the Windows version as well so that both
implementations share
a big portion of the code.
The underlying PeerConnection notifications have changed a bit since the last
update
so that there's still a known issue that I plan to fix in my next change:
// TODO(tommi): There's a problem now with terminating connections:
// When ending a conversation, both peers now send a signaling message
// that indicates that their ports are closed (port=0). The trouble this
// causes us here is that we can interpret such a message as an invite
// to a new conversation. So, currently there is a bug that ending
// a conversation can immediately start a new one.
// To fix this I plan to change how conversations start and have a special
// notification message via the server that prepares a client for a
// conversation instead of automatically recognizing the first signaling
// message as an invite.
Review URL: http://webrtc-codereview.appspot.com/112008
git-svn-id: http://webrtc.googlecode.com/svn/trunk@446 4adac7df-926f-26a2-2b94-8c16560cd09d
