posted May 2, 2012 6:19 AM by Serge Lachapelle
Hi!
The good: As we move closer to a stable release, we want to be comply with the proposed W3C API as much as possible. The less good: This means that several of your incredible demos will need a minor tiny update.
1st change: getUserMedia
The spec ( http://dev.w3.org/2011/webrtc/editor/getusermedia.html ) advocates the use of an object based argument syntax. Example:
Before:
navigator.webkitGetUserMedia("audio,video", gotStream, gotStreamFailed);
After:
navigator.webkitGetUserMedia({audio:true, video:true}, gotStream, gotStreamFailed);
This change has been submitted and will be a part of Chrome Canary soon.
2nd change: PeerConnection00
The second change affects the new PeerConnection API called JSEP ( http://tools.ietf.org/html/draft-uberti-rtcweb-jsep-02 ). The older, soon to be deprecated, webkitDeprecatedPeerConnection API is not affected by this.
Similarly to webkitGetUserMedia, webkitPeerConnection00 also advocates the use of an object based argument syntax.
This change has not been submitted yet, but we expect it to land soon.
createOffer & createAnswer requires a MediaHints dictionary with the following properties:
has_audio: boolean
has_video: boolean
startIce now takes an IceOptions dictionary with the following property:
use_candidates: "all", "no_relay", "only_relay"
addStream now takes a MediaStreamHints dictionary for future usage.
All these four APIs previously required string arguments. We expect further changes in the valid keys for these objects. We will be able to support backwards compatibility for those changes.
3rd change, a new Chrome flag
webkitGetUserMedia() has proven very popular with developers. It enables local camera and microphone access and can be used for taking pictures, for games, etc...
To allow us to deliver this popular functionality independently of the complete WebRTC package, we have decided to split the webkitGetUserMedia and PeerConnection implementation (both webkitPeerConnection00 and webkitDeprecatedPeerConnection) into two flags:
--enable-media-stream is the master flag. It will enable getUserMedia functionality giving you access to camera and microphone.
In order to establish an audio and video connection between two browsers, you will now need to also enable:
--enable-peer-connection
The last two changes are not yet in, but we wanted to give you a heads up. I will send an update once they start showing up on Canary.
Thank you for all your great demos and feedback.
/Serge
|
posted Mar 14, 2012 8:16 AM by Serge Lachapelle
( cross posted from the WebRTC Google+ page ) In today's forecast, we expect to see sunny skies and a chance of breakage. If you have been writing WebRTC demos with Chrome, this will affect your demo. The Chrome WebRTC (that's us!) team is very active at both the W3C and IETF to get the APIs in tip top shape. Our goal is to have our implementation follow the API quickly. The result? Chrome Canary and Chrome Dev will go through major changes, starting today, that will break your existing work. Fortunately, fixing is easy! Please read the following carefully: 1. The current PeerConnection API is now renamed DeprecatedPeerConnection. We are keeping the old PeerConnection around to give you time to move to it. A simple rename will keep your demos working. DeprecatedPeerConnection will be deleted a short while after JSEP is fully intergrated into the WebRTC standard and PeerConnection00 is renamed PeerConnection. 2. We are working on the new PeerConnection API. It's not done yet. JSEP is a new signalling API that is described in this internet draft: http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-00 The WebRTC W3C workgroup is working on integrating this draft into the W3C Specification. The new JSEP PeerConnection will be called PeerConnection00 We will keep a version number until the W3C workgroup finalizes the standard. By using version numbers, we can hopefully avoid "hard" breakage like the one we are causing now. If you adopt this new version, you will be closer to the final spec, but you will have to expect breakage if we update from 00 to 01 and so on. You will notice that JSEP allows lower level operations, but is more complex. To offset this complexity, + Harald Tveit Alvestrand created a Javascript library that abstracts JSEP and mimics the "old" way of doing things. You can find it here: http://code.google.com/p/webrtc-samples/source/browse/#svn%2Ftrunk%2Froap-jsep Disclaimer: It's a first version but should be useful to keep your old demos running once we switch fully to JSEP. Here is the timeline we expect to follow: • Today's PeerConnection is being renamed DeprecatedPeerConnection (NOW for Canary, soon for Chrome Dev.) • A new experimental PeerConnection will be introduced as PeerConnection00 (gradually during the next few weeks) • As the JSEP draft iterates PeerConnection00 might become PeerConnection01. The old PeerConnection00 won't stay around. • When the standard is fully updated with the final JSEP API PeerConnection00 (or PeerConnection01 etc) will be updated accordingly and renamed PeerConnection. • A few weeks later (tops) DeprecatedPC will be deleted. The demos, issues and comments you have sent us are extremely motivating. We hope you will take the time to replace the string "PeerConnection" with "DeprecatedPeerConnection" in your code. Iterating an early standard is a challenge and we apologize for the inconvenience. I promise to update this page frequently and answer questions about this quickly. The WebKit bug entries that can be used to track the chaos are: Overall move to JSEP https://bugs.webkit.org/show_bug.cgi?id=80589 |
posted Mar 5, 2012 2:21 PM by Serge Lachapelle
Our goal is to keep this app updated to work with the latest Chrome code and to keep the code simple enough for everyone to use as an example or to simply learn about WebRTC.
If you find bugs, feel free to send us a patch and we will commit it. We will avoid adding to many features as simplicity and education is the goal here.
Hope this helps! |
posted Mar 1, 2012 6:14 AM by Niklas Enbom
[
updated Mar 1, 2012 6:22 AM
]
From today's canary (19.0.1057) we have added a user consent UI for a web page to access input devices such as camera and microphones. Currently this works on Windows only, Linux and Mac support is on its way. Privacy and security are very important topics for WebRTC, and exactly how this should be handled is discussed a lot in w3c and IETF, so expect changes going forward. |
posted Feb 21, 2012 2:50 AM by Serge Lachapelle
With the help of our friends Peter, Joe, Clara and Johan from protothon.com, we are organizing a day long event on Saturday, March 24th 2012 in Stockholm Sweden. Prototype hacking with WebRTC.
While some of you may think it is very early to do such an event, we think the timing is perfect: - Software designers should get a kick out of being amongst the first playing with this technology, and influencing it's outcome.
- We get hugely valuable feedback, the kind of hands-on feedback usually not present in API specification discussions.
We will have, on hand, people that have written and edited the WebRTC API, people that have implemented it in Chrome / WebKit and signal processing experts that make the magic happen underneath the APIs and browser integrations.
Our goal until then is to get the latest JSEP proposal implemented in Chrome, make an abstraction JS library available (for simplicity) and get the apprtc.appspot.com demo open sourced.
Hope you will sign up... ( here)! |
posted Feb 9, 2012 6:06 AM by Serge Lachapelle
Hi,
The Chrome WebRTC package has changed this week for user of Chrome Canary and Dev channels. We thought it would be a good idea to drop a note on the blog as we have not yet caught up with updating our own documentation. - The Chrome implementation of the WebRTC API is now a closer match to current W3C WebRTC API draft. It includes the ability for separate audio / video sessions. (ref: Stream API)
- SRTP (encryption) now on by default, meaning all audio and video data will be encrypted. This will maybe break a few early phone interop demos.
- Signaling is now built using ROAP. Another proposal, which has gained some consensus, is JSEP. We are tracking this closely.
Hints on how to migrate your early prototypes can be found in this changelist. |
posted Feb 2, 2012 6:23 AM by Serge Lachapelle
Quick note: Chrome Canary now support calling with only audio or only video. |
posted Jan 25, 2012 5:28 AM by Serge Lachapelle
Hi,
Today, we posted a page that includes instructions for enabling WebRTC in Chrome and testing it out on a few user submitted demoes. You can now enable WebRTC using chrome://flags
|
posted Jan 18, 2012 9:01 AM by Serge Lachapelle
Today, we made available the WebRTC API and its underlying components on the Chrome dev channel. This release implements a slightly older version of the W3C spec. The spec is evolving rapidly, but now that we have WebRTC wired up in Chrome, we plan to catch up to it quickly.
We thought it would be a good idea to provide some additional details for those interested in trying it out.
Who should use this? WebRTC should be interesting to developers who want to add real time communication capabilities to their apps. However, please note that WebRTC is still evolving. We consider it an early beta so your feedback will be critical for future releases.
How do I enable WebRTC? Please switch to the Chrome Dev Channel by following the instructions on this page. Then start Chrome with this switch: " --enable-media-stream"
How can I try it out? The source code at webrtc.org includes a sample application. Follow these instructions to download and run it. We are also working on a AppEngine hosted demo that will be up shortly. Watch this blog for details.
Where should I provide feedback? Feedback for the WebRTC API should be sent to the W3C list. Underlying protocol choices are discussed on the IETF list.
Feedback on our implementation is best sent to our WebRTC discussion list. To file issues, please use our bug tracker which can be found here.
We look forward to working with all of you!
Niklas Enbom, Software Engineer |
posted Nov 8, 2011 7:15 AM by Serge Lachapelle
The blog and twitter have been fairly quiet. Team is heads down on several fronts: - Upcoming IETF in Taiwan, where Harald, Serge and Justin will be attending. (please come and say hi) You will also notice the high degree of activity on the email lists.
- W3C first draft of the API.
- Getting webkit patches landed, enabling us to get a WebRTC enabled version of Chrome to the public. You'll notice the brilliant work by Ericsson, whom have been helping out a ton in driving this.
- Optimize, Optimize, Optimize.
Hopefully our next post will be soon, and will include a more useful URL :) |
|
