First, be sure to install the prerequisite software.
For desktop development:
$ mkdir webrtc-checkout $ cd webrtc-checkout $ fetch --nohooks webrtc $ gclient sync
NOTICE: During your first sync, you'll have to accept the license agreement of the Google Play Services SDK.
The checkout size is large due the use of the Chromium build toolchain and many dependencies. Estimated size:
$ git config branch.autosetupmerge always $ git config branch.autosetuprebase always
$ cd src $ git checkout main $ git new-branch your-branch-name
NOTICE: if you get
Remote: Daily bandwidth rate limit exceeded for <ip>, make sure you're logged in. The quota is much larger for logged in users.
Update your current branch with:
$ git checkout main $ git pull origin main $ gclient sync $ git checkout my-branch $ git merge main
Ninja is the default build system for all platforms.
To generate project files using the defaults (Debug build), run (standing in the src/ directory of your checkout):
$ gn gen out/Default
To generate ninja project files for a Release build instead:
$ gn gen out/Default --args='is_debug=false'
To clean all build artifacts in a directory but leave the current GN configuration untouched (stored in the args.gn file), do:
$ gn clean out/Default
To build the fuzzers residing in the test/fuzzers directory, use
$ gn gen out/fuzzers --args='use_libfuzzer=true optimize_for_fuzzing=true'
Depending on the fuzzer additional arguments like
is_ubsan_security might be required.
When you have Ninja project files generated (see previous section), compile (standing in
For Ninja project files generated in
$ ninja -C out/Default
To build everything in the generated folder (
$ ninja all -C out/Default
See Ninja build rules to read more about difference between
Other build systems are not supported (and may fail), such as Visual Studio on Windows or Xcode on OSX. GN supports a hybrid approach of using Ninja for building, but Visual Studio/Xcode for editing and driving compilation.
To see available release branches, run:
$ git branch -r
To create a local branch tracking a remote release branch (in this example, the branch corresponding to Chrome M80):
$ git checkout -b my_branch refs/remotes/branch-heads/3987 $ gclient sync
NOTICE: depot_tools are not tracked with your checkout, so it's possible gclient sync will break on sufficiently old branches. In that case, you can try using an older depot_tools:
which gclient $ # cd to depot_tools dir $ # edit update_depot_tools; add an exit command at the top of the file $ git log # find a hash close to the date when the branch happened $ git checkout <hash> $ cd ~/dev/webrtc/src $ gclient sync $ # When done, go back to depot_tools, git reset --hard, run gclient again and $ # verify the current branch becomes REMOTE:origin/main
The above is untested and unsupported, but it might help.
Commit log for the branch: https://webrtc.googlesource.com/src/+log/branch-heads/3987 To browse it: https://webrtc.googlesource.com/src/+/branch-heads/3987
For more details, read Chromium's Working with Branches and Working with Release Branches pages. To find the branch corresponding to a Chrome release check the [Chromium Dashboard][https://chromiumdash.appspot.com/branches].
Please see Contributing Fixes for information on how to run
git cl upload, getting your patch reviewed, and getting it submitted. You can also find info on how to run trybots and applying for try rights.
Many WebRTC committers are also Chromium committers. To make sure to use the right account for pushing commits to WebRTC, use the
user.email Git config setting. The recommended way is to have the chromium.org account set globally as described at the depot tools setup page and then set
user.email locally for the WebRTC repos using (change to your webrtc.org address):
$ cd /path/to/webrtc/src $ git config user.email email@example.com
WebRTC contains several example applications, which can be found under
src/webrtc/examples. Higher level applications are listed first.
Peerconnection consist of two applications using the WebRTC Native APIs:
peerconnection_client(not currently supported on Mac/Android)
The client application has simple voice and video capabilities. The server enables client applications to initiate a call between clients by managing signaling messages generated by the clients.
peerconnection_server. You should see the following message indicating that it is running:
Server listening on port 8888
Start any number of
peerconnection_clients and connect them to the server. The client UI consists of a few parts:
Connecting to a server: When the application is started you must specify which machine (by IP address) the server application is running on. Once that is done you can press Connect or the return button.
Select a peer: Once successfully connected to a server, you can connect to a peer by double-clicking or select+press return on a peer's name.
Video chat: When a peer has been successfully connected to, a video chat will be displayed in full window.
Ending chat session: Press Esc. You will now be back to selecting a peer.
Ending connection: Press Esc and you will now be able to select which server to connect to.
Start an instance of
src/webrtc/examples/peerconnection/server/server_test.html in your browser. Click Connect. Observe that the
peerconnection_server announces your connection. Open one more tab using the same page. Connect it too (with a different name). It is now possible to exchange messages between the connected peers.
stunserver. Implements the STUN protocol for Session Traversal Utilities for NAT as documented in RFC 5389.
turnserver. Used for unit tests.