Chrome

How to reach the Chrome WebRTC team

For any questions, comments or stories you would like to share, please join our discussion list or engage us on Google+.

For specific issues with the code, please use our issue tracker:

Press enquiries should be sent to press@google.com

How do I contribute code?

We welcome external contributors! Go here if you are interested. Or, you can just download the code and play around with the samples to get started. 

Where can i find Chrome WebRTC Release Notes?

You can find Chrome WebRTC Release Notes here.

Tests and Continuous Integration

There's a lot of tests for WebRTC that ensure that the code.webrtc.org code and WebRTC-in-Chrome is healthy. Read more about that here. Also, the quality dashboard will provide quality metrics, such as our code coverage and performance test results (e.g. automated CPU/Memory tests, video quality tests, and the like).

Chrome implementation details

Both getUserMedia and PeerConnection are implemented and shipping in the desktop version of Chrome for Windows, Linux and Mac. These APIs do not require any flags or command line switches to use as they are now part of Chrome Stable.

Here are some frequently asked questions about the current implementation:

What are some chromium command-line flags relevant to WebRTC development/testing?

  • --allow-file-access-from-files: allows getUserMedia() to be called from file:// URLs.
  • --disable-gesture-requirement-for-media-playback: removes the need to tap a <video> element to start it playing on Android
  • --use-fake-ui-for-media-stream: avoid the need to grant camera/microphone permissions
  • --use-fake-device-for-media-stream: feed a test pattern to getUserMedia() instead of live camera input
  • --use-file-for-fake-video-capture=path/to/file.y4m: feed a Y4M test file to getUserMedia() instead of live camera input

Can I use the microphone input from GetUserMedia for local playback?

No, the <audio> tag does not support MediaStreams yet but it is currently being worked on.

Can you summarize the evolution of the PeerConnection API changes? 

 There have been many changes. Here is a little history and background and the latest (Oct 1st 2012, Chrome M23).

  1. The first implementation of PeerConnection API was changed to webkitDeprecatedPeerConnection and the latest implementation webkitPeerConnection00  was introduced. This reason for this is detailed in a blog post but, in short, we switched from a ROAP based signalling mechanism to JSEP.
  2. webkitDeprecatedPeerConnection was removed and replaced by webkitPeerConnection00.
  3. The W3C made further significant changes, including a naming convention change. Chrome M23 introduces RTCPeerConnection. Since this is what will be shipping in Chrome, we have moved webkitPeerConnection00 behind a flag. Here is what we have implemented in Chrome:

We have implemented http://www.w3.org/TR/2012/WD-webrtc-20120821/

with these two APIs:
    void        createAnswer (RTCSessionDescriptionCallback successCallback, optional RTCPeerConnectionErrorCallback? failureCallback = null, optional MediaConstraints constraints = null);
    void        updateIce (optional RTCConfiguration? configuration = null, optional MediaConstraints? constraints = null);
instead of :
    void        createAnswer (RTCSessionDescription offer, RTCSessionDescriptionCallback successCallback, optional RTCPeerConnectionErrorCallback? failure Callback = null, optional MediaConstraints constraints = null, optional boolean createProvisionalAnswer = false);
    void        updateIce (optional RTCConfiguration? configuration = null, optional MediaConstraints? constraints = null, optional boolean restart = false);

Data Channels?

The standard compliant SCTP-based DataChannel implementation has been released in Chrome M32. You do not need to specify any constraint in order to use the SCTP-based DataChannels in Chrome. For the standalone WebRtc build, however, DTLS must be enabled by either the "DtlsSrtpKeyAgreement:true" constraint or providing your own implementation of DTLSIdentityServiceInterface to PeerConnectionFactoryInterface::CreatePeerConnection.

The following information only applies to the now deprecated RTP-based DataChannel. 


An initial implementation can be found in Chrome v25. While the API matches the standard, please be aware that the actual network bits flowing over the network do not match the spec, and that a special flag and constraint parameter must be given. 

To enable DataChannels in Chrome  M25 there are several things you need to do:

- Start Chrome with the flag --enable-data-channels

- When a peerconnection is created you need to create it with the  constraints RtpDataChannels.
servers = {iceServers:[{url:"stun:stun.l.google.com:19302"}]};
peerConnection = new webkitRTCPeerConnection(servers, { optional:[ { RtpDataChannels: true } ]});

- Only unreliable data channels are supported. To Create a data channel:
dataChannel = peerConnection.createDataChannel("a label", { reliable : false });

- After a data channel has been created-  an offer and an answer must be exchanged with the remote peer. Same as when a MediaStream has been added or removed.

Knows issues (except for the above limitations):
DataChannels never transit to Open state if it is created when audio an video is already flowing

TURN?

TURN support has been introduced in Chrome 24.

OPUS?

OPUS audio codec support was introduced in Chrome 24.

Recording?

Recording does not have a stable specification yet and our current focus is on PeerConnection. A draft of this API was posted in 2012. It can be found here.

DTMF support?

An initial, no guarantee given estimate is Chrome v26.

Internet Explorer?

WebRTC support for Internet Explorer has been tested on Chrome Frame for Internet Explorer users in non-metro mode.

Comments