Placeholder Image

字幕列表 影片播放

  • JUSTIN UBERTI: So what you all think of the Google Glass

  • Hangout this morning?

  • [AUDIENCE CHEERING]

  • JUSTIN UBERTI: What an amazing way to show off the power of

  • real-time communication.

  • When I first heard about it, they're going to jump out of

  • an airship and have it all in a Hangout, I was like, that's

  • pretty incredible.

  • But anyway, I'm Justin Uberti.

  • And today, I'd like to tell you all about WebRTC, a

  • project to bring real-time communication--

  • RTC--

  • to the open web platform.

  • So I currently work on the WebRTC team here at Google,

  • which is part of the Chrome project.

  • Before joining WebRTC, I was the lead in the Google Talk

  • team, where we built some really exciting applications,

  • and also learned a lot of really hard lessons about what

  • it takes to do these kinds of apps in a browser.

  • I also kind of learned that some people on the internet

  • think I have really small hands.

  • I don't get it.

  • So enough about me.

  • Let me see what kind of developers we have in the

  • audience today.

  • Raise your hand if you're really familiar with the

  • following technologies.

  • WebRTC?

  • OK.

  • HTML5?

  • Good.

  • WebSockets?

  • App Engine?

  • SIP?

  • OK.

  • H 323?

  • OK.

  • You folks who raised your hands, you have my

  • condolences.

  • So what exactly is WebRTC?

  • Well, let me tell you a little story.

  • A couple years ago, when we are working on what would

  • become Hangouts, the Chrome team approached us.

  • And they said, the open web platform has some amazing

  • technology.

  • And people are building incredible apps with it.

  • But there's one big gap remaining.

  • To build apps like Google Video Chat, you need plugins.

  • And these plugins have all sorts of problems, security,

  • everything.

  • What would it take to take the stuff you built for Google

  • Video Chat and Hangouts, and make it part of

  • the open web platform?

  • Well, we said, it would be really complicated.

  • I mean, we'd have all these technology

  • issues to figure out.

  • And we'd have to deal with like codec

  • licensing, and open sourcing.

  • And most of all, we'd have to work with other browser

  • manufacturers and other industry players to make an

  • actual standard for something that can be implemented across

  • all browsers and across the entire web.

  • And so in typical Google fashion, the response we got

  • back was, sounds like a plan.

  • When can we have it?

  • So we got to work.

  • Where we didn't have the right technology pieces in house, we

  • went out and we acquired state of the art, the very best

  • technology out there.

  • We assembled these pieces into a system.

  • And as we started talking to other people, and we talked to

  • other browser manufacturers, Firefox, Opera, Microsoft.

  • We talked to people who would build apps on this platform,

  • people like Skype, people like Cisco.

  • And we talked to the typical telecom providers, folks like

  • Ericsson, AT&T.

  • They were all super excited about this because it's

  • potential, not just for the web, but for the entire

  • communications industry.

  • So that's the premise of WebRTC, RTC to build real-time

  • communications into the fabric of the web, where every

  • browser has a built in, state of the art communication

  • stack, and create a new open platform that any application

  • and any device can use to communicate.

  • So think about that.

  • This is where we're having, the ability to get the

  • communications industry--

  • a $2 trillion industry--

  • moving at web speed.

  • And not only will the developers be able to build

  • and deploy voice and video apps, just like any other web

  • app, but we'll also start to see communication being built

  • in as a feature to all sorts of apps.

  • In a game, the ability to see the opponent's face right as

  • you checkmate them.

  • Or in customer service on a website, a shopping website,

  • to be able to talk to a customer service rep live in

  • person with a single click.

  • As WebRTC takes hold across computers and all sorts of

  • devices, we have the real ability to create the next

  • generation phone network, where every WebRTC enabled

  • device can communicate with amazing

  • audio and video quality.

  • So take this quote from NoJitter.

  • This is a communications industry blog.

  • "WebRTC and HTML5 could enable the same transformation for

  • real time that the original browser did for information."

  • That's a pretty lofty comparison.

  • So how do we get there?

  • Well first, we need to get WebRTC in the hands of you,

  • the developers.

  • And here's where we're at with that.

  • The first WebRTC support is now shipping in Chrome 21, the

  • current Chrome Dev track.

  • And also in Opera 12.

  • We're expecting to have Firefox join us before the end

  • of the year.

  • We've also brought WebRTC support to Internet Explorer

  • via ChromeFrame.

  • And so we'll soon have support across

  • almost all desktop browsers.

  • As this technology stabilizes, we're also going to see web

  • WebRTC start to appear in the various mobile browsers.

  • And for those building native applications, either on

  • desktop or mobile, we have native versions of the WebRTC

  • stack that are fully compatible with their web

  • counterparts.

  • So the functionality the WebRTC offers falls into three

  • categories.

  • The first, MediaStreams, also known as get user media, is

  • about getting access to the user's camera and mic.

  • There are a lot of cool apps that can be

  • built with just this.

  • Next the technology called PeerConnection.

  • This is the engine behind making high quality peer to

  • peer voice and video calls on the web.

  • Last is a new bit of functionality called

  • DataChannels.

  • It's so new, the spec for this hasn't fully stabilized yet.

  • But it has incredible potential.

  • The ability for any web app to be a P2P app, to exchange

  • application data peer to peer.

  • Now let's take a look at each one of these.

  • Now, if you're following along at home, and you want to try

  • out the things about the show, and you're running Chrome, you

  • want to turn on the flags to enable MediaStreams and

  • PeerConnection.

  • If you go to About Flags in your Chrome build, you'll see

  • these options in a list.

  • And you turn on MediaStream and PeerConnection.

  • In the Dev channel on Chrome 21, you won't see a

  • MediaStream option, because it's now on by default.

  • And if you don't want to turn this on for your existing

  • version of Chrome, you can download Google Chrome Canary

  • and run it side by side with your

  • existing version of Chrome.

  • So first up, MediaStreams.

  • A MediaStream represents a media source, and can contain

  • multiple media tracks that can be of various types.

  • So for example, if we get a MediaStream for the user's

  • webcam and mic, we'll have a single stream, but a track for

  • video, and a track for audio, as shown in the diagram here.

  • Now, in a video conference, we could have multiple

  • MediaStreams.

  • And one MediaStream would exist for each participant,

  • each one with an audio and video track.

  • Now, once we have a MediaStream we need a way to

  • actually play it out.

  • And fortunately, we have an easy way to play audio and

  • video in HTML via the aptly named,

  • audio and video elements.

  • Now, in order to plug a MediaStream into these

  • elements, we first need a way to get a URL that references

  • the MediaStream.

  • Fortunately, there's a method called create object URL that

  • does just that.

  • Plug that URL into a tag, and then media will start to play.

  • Now lastly, how do we get the MediaStream for

  • the webcam and mic?

  • So there's a new API called getUserMedia.

  • In Chrome, it's prefixed as WebKit getUserMedia.

  • And the API is async.

  • So you call it, it prompts the user for permission to access

  • their devices.

  • We spend a lot of time worrying

  • about privacy and security.

  • And that gives you back a MediaStream via callback once

  • it's successful.

  • So here's that all put together.

  • Get user media, get a callback, create URL, stuff it

  • in a video tag.

  • So let's see that in action.

  • So here we get prompted for our camera.

  • I'll pick my good camera right here.

  • And there it is.

  • Webcam access right in the browser.

  • Pretty cool.

  • So now let's jazz it up a little bit.

  • So the first thing that everybody does with

  • getUserMedia is to make a Photo Booth app.

  • And we're not going to be any exception.

  • So let's add a button so that we can draw the current video

  • frame directly onto a campus, just like a camera.

  • So let's try that out.

  • So here's our next sample.

  • Get prompted.

  • This time I'm going to tell it to remember it, so I don't

  • want you to do this again.

  • OK, and so give a big thumbs up for the camera here.

  • And there's our Photo Booth.

  • So of course, all good Photo Booths need some

  • sort of video effects.

  • The web platform gives us some great tools to do this.

  • With CSS, we can apply a style to any visual element, like a

  • video tag or a canvas.

  • So here, we can apply a black and white effect, this built

  • in webkit gray scale CSS.

  • And so when the button is clicked, we're going to apply

  • that CSS class to the video element.

  • So I've made a demo.

  • And I've got a couple more effects in here.

  • So let me show them to you now.

  • So I start up.

  • And since I've remembered the preference, it doesn't need to

  • prompt me again.

  • So let me try, we got sepia tone here.

  • And let's see, there's blur.

  • And there's black and white.

  • And I like black and white, it looks real serious.

  • So there's a lot of cool stuff you can do

  • just with these things.

  • Now, that's what you can do with a few lines of code.

  • But I want to show you now a complete Photo Booth

  • application that uses this technology.

  • And the app I'm about to show you is called Webcam Toy.

  • And it's written by a guy named Paul Neave, who got

  • involved with WebRTC in the very, very beginning.

  • And so this thing uses Canvas and WebGL pixel shaders to do

  • some really amazing effects.

  • There's over 100 effects in this app.

  • So there's some really cool ones.

  • Like, let me show you.

  • This one's one of my favorites here.

  • Snow, it comes down and it sort of builds up and stuff.

  • And you can kind of clear it off and stuff.

  • It's really cool.

  • And let's see, what else?

  • The sketch one, this is also one of my favorites.

  • But what I really want to do is I'm going to take a picture

  • this room so I can remember this moment here.

  • All right, what's a good effect?

  • I like this one.

  • [CAMERA SHUTTER SOUND]

  • JUSTIN UBERTI: All right, immortalized forever.

  • OK, so one other thing that Paul has done, though, is he's

  • wired getUserMedia to do real-time face recognition in

  • JavaScript.

  • So here we have real-time face detection running in

  • JavaScript.

  • Now, I never thought I would be saying those words.

  • But here it is, as long as I look at the camera.

  • So this kind of gives a new meaning to

  • Chrome's incognito mode.

  • So as you can see, some amazing things are possible

  • when we combine WebRTC with the rest of the web platform.

  • OK, so that's how we get access to devices.

  • Now PeerConnection Connection will let us take those

  • MediaStreams and send them across the

  • internet peer to peer.

  • So PeerConnection, as its name indicates, is the API they use

  • to set up peer to peer sessions.

  • And it handles all the tricky parts you need to establish a

  • connection and run audio/video over it, establishing the P2P

  • link, managing the various audio and video codecs,

  • encryption, tuning the audio/video stream to make

  • best use of the available bandwidth.

  • But before we get into how PeerConnection works, let's

  • take a look at a typical voice video application.

  • I have Google Talk, let's set up a call.

  • So the app wants to be able to send the media directly to the

  • other side.

  • But in order to do so, it needs to establish the direct

  • link and the details of how the media should be sent.

  • And the way it does that is sort of by randevuing through

  • the cloud by sending signaling messages over its connection

  • using a protocol like XMPP or SIP.

  • And these messages are relayed to the other side.

  • This exchange of parameters allows both sides to

  • successfully randevu and establish the call.

  • Now, what we could have just taken that logic and stuffed

  • it into the browser.

  • The app would just tell the browser where to connect to

  • and to establish a SIP or XMPP connection, just like a

  • desktop app.

  • But this isn't my makes sense for a couple reasons.

  • The app already has a connection to

  • the cloud using HTTP.

  • And if we bake the signaling protocol into the browser,

  • we'd have to pick one that everybody could agree on.

  • That doesn't seem too likely, given the various apps that

  • are out there.

  • And lastly, this connection would have to deal with all

  • the proxy and Firewall issues that HTTP has already solved.

  • So we didn't do this.

  • What did we do?

  • So we have an approach that's called JSEP--

  • JavaScript Session Establishment Protocol.

  • And we thought, let's put the minimum we

  • need into the browser.

  • In 2012, that's peer to peer networking, codecs, and

  • encryption.

  • And let the app do all the rest.

  • The app can manage all the call setup, using whatever

  • mechanism it wants.

  • The app will simply tell the browser about the parameters

  • it wants to use for the call using things we call session

  • descriptions.

  • As long as the app has some way to exchange session

  • descriptions with the other side, it can do this any way

  • that it wants to.

  • So for example, we could use App Engine and use XML HTTP

  • Request to post the session descriptions using an adjacent

  • encoding to App Engine.

  • And have App Engine deliver them to the remote side using

  • the App Engine channel API.

  • Or we could actually implement the SIP protocol in

  • JavaScript, convert the session descriptions to SIP

  • messages and send them to existing SIP

  • equipment out there.

  • And so there's a ton of existing SIP equipment, the

  • phone network, soft switches, existing enterprise video

  • conferencing equipment.

  • And people are already using this today to have SIP Interop

  • with WebRTC without forcing WebRTC to have SIP built in.

  • So the abstract PeerConnection API allows us to handle either

  • of these cases, along with a whole set of others that I

  • haven't mentioned.

  • Now, the basic thing that a PeerConnection needs is in

  • local session description, which holds the local

  • parameters for the call in the remote session description,

  • which indicates the remote parameters.

  • It also needs the transport candidates, which are the IP

  • addresses and ports that the remote side is reachable at.

  • Sometimes these are included within the session

  • description.

  • Now, I'm going to walk through a call setup, and show how

  • these parameters are exchanged.

  • One thing to note, the initial parameters sent by the caller

  • specify everything that a caller is capable of.

  • And we call that an offer.

  • The response from the callee, which indicates the negotiated

  • or selected parameters, is called an answer.

  • So here's the first thing.

  • The app creates the local session description, the

  • offer, passes into the PeerConnection API, and sends

  • it to the remote side using whatever mechanism it wants.

  • The caller gets it and gives it to the PeerConnection API

  • as the remote description.

  • Then, assuming that the callee accepts the call, generates

  • their own session description, passes it into PeerConnection,

  • and sends it back to the caller as an answer.

  • The caller gets that answer and gives it to PeerConnection

  • as a receive session description.

  • Now, at this point, the browser has everything it

  • needs to establish the call, the local session description,

  • the remote session description, the transport

  • candidates, the P2P link gets established, and media flows.

  • So let's look at what this looks like in code.

  • The caller creates a PeerConnection, plugs a

  • MediaStream into it, which it got from the getUserMedia API

  • via add stream.

  • It then creates an offer, plugs it in, and sends it off

  • to the callee.

  • When the callee gets it, over here on the right, it creates

  • a PeerConnection, stuffs in the offer via set remote

  • description, and then creates its own session description as

  • an answer that it can send back to the caller.

  • The caller then gets its answer on the left, sets call

  • set remote description with the received answer, and the

  • set up is complete.

  • So let's see how this looks like in code.

  • We're going to do the offer/answer dance here in a

  • single web page with two PeerConnections.

  • Instead of sending these messages across the internet,

  • we're going to just stuff them directly into the appropriate

  • PeerConnection So let's try this out.

  • Still like this incognito mode.

  • OK.

  • So we start up the camera.

  • And now, when we hit the call button, we're going to spin up

  • all the codec, P2P, crypto, all that sort of stuff.

  • And we should see the video appear in the panel on the

  • right as what the remote user would see.

  • Bang, there it is.

  • Now, let me show you that again.

  • I'm going to hang it up and call again.

  • And there it goes.

  • So you'll see that we have this functionality.

  • And as long as it's sending session descriptions back and

  • forth, the rest of it pretty much manages itself.

  • Now, that's kind of cheating.

  • You know, passing the data back and forth in a single web

  • page isn't really that interesting from

  • a video call scenario.

  • We want to call someone on the other side of the planet, not

  • in the same web page.

  • So how are we to do This Well, in order to make this into a

  • real video calling app, we need to send those session

  • descriptions across the internet.

  • Now, let's look at how we can do that.

  • So it's really easy to send a session

  • description to the cloud.

  • We just make it into a string, and shoot it off

  • over XML HTTP Request.

  • But how can we receive them?

  • Especially when this is a real-time application.

  • The caller doesn't want to sit there forever

  • waiting for the callee.

  • We don't want to spend a lot of time polling.

  • What can we do?

  • Well, App Engine gives us a great tool for this.

  • The Channel API provides an easy to use, server to client

  • signaling path for pushing session descriptions from the

  • server to the client.

  • And App Engine takes care of all the details.

  • No matter how many users you have, or where users are in

  • the world, you can use the same simple API

  • to send down messages.

  • So here's how it works.

  • The first thing you do is establish a channel.

  • You can do this when serving the web page to eliminate a

  • round trip.

  • So in the server, you simply create a Channel API token and

  • send it down in the web page response.

  • The app then uses the JavaScript API with that token

  • to bring up the back channel, and you're ready to rock.

  • You can send messages from your server

  • down to your client.

  • So here we have Client B that wants to send a message and

  • link the session description to Client A. It does so

  • typically [? in the ?]

  • POST using XML HTTP Request to get the

  • message up to App Engine.

  • And then it codes an identifier to indicate who it

  • should be sent to.

  • Now, your app can use the identifier to find the right

  • channel instance on the server side.

  • And once it does that, you simply call [? send ?]

  • the channel.

  • And it gets pushed down to Client A who receives it in a

  • JavaScript callback, super easy.

  • So here's a snippet that shows how this all works.

  • At the top, the client brings up the back channel using the

  • App Engine API.

  • Then, when it gets an incoming call message in its callback,

  • we can set the remote and local descriptions, create an

  • answer, and then shoot that back using XHR.

  • So these are some great little examples to sort of show the

  • basics of the API.

  • But we also want to have a complete video calling

  • application, a reference sample application, where we

  • can show developers the best ways to bring

  • this stuff all together.

  • And we also want it to be the kind of application that we

  • can use in our daily work, not just a sample app, something

  • that will be a full-fledged reference application.

  • So we created AppRTC.

  • It runs on App Engine using things like Channel API and

  • Data Store, and shows how to use the WebRTC APIs, handling

  • session descriptions, making call setup fast, and showing

  • NAT Traversal works.

  • And every AppRTC call is fully encrypted.

  • Now, I really want to show this to you.

  • So we've got some people on the team.

  • And they've been working really hard on

  • some updates to AppRTC.

  • Now, I want to just sort of check in with them real quick

  • and make sure that they're not getting too stressed out.

  • So let's do that now.

  • OK.

  • Hey, Ray.

  • You look pretty relaxed there.

  • Did you get that work done I wanted you to do?

  • RAY: Yep, yep, sure did.

  • WebRTC and App Engine took care of the

  • most complicated stuff.

  • So I'm done, Justin.

  • JUSTIN UBERTI: Well, I mean, let me say, it looks great.

  • I mean, not just the app, but also your pool.

  • You know, I wish I could swing by later.

  • Anyway, I've got to get back to the session.

  • It's going great.

  • And I'll let you get back to relaxing.

  • Catch you later, Ray.

  • RAY: See you, Justin.

  • [APPLAUSE]

  • JUSTIN UBERTI: So that's the kind of quality that you can

  • accomplish with WebRTC.

  • Real calls across the internet, right

  • from your web browser.

  • OK, so we just showed how to send audio and

  • video peer to peer.

  • But what if we just want to send data?

  • Well, enter DataChannels.

  • So DataChannels designed to allow apps to exchange

  • arbitrary application data with low latency, high

  • throughput and message rate, and optionally unreliable

  • semantics so you keep chugging, even

  • if you lose a packet.

  • Now, there are lots of great real world use cases that

  • DataChannels are great for.

  • If you have a game, and you want to send the positions of

  • bullets in a game, you don't want to send that data over

  • HTTP, to the server and back with all the HTTP overhead.

  • You can instead send it in a very tight, efficient message

  • over the peer to peer channel.

  • For remote desktop apps, you can do things like track the

  • position of the mouse with great responsiveness.

  • And there's a lot of other great examples.

  • But one I particularly like is the ability to create a

  • secure, decentralized network.

  • And you can imagine, in a place were there's censorship

  • of the internet, you could provide this mechanism as a

  • way where people can communicate over a private

  • encrypted channel.

  • So here are the key features of the DataChannel.

  • To set it up, we're going to leverage the

  • PeerConnection setup.

  • You do this sort of offer/answer dance.

  • We'll get the channel bootstrapped.

  • But then you can create multiple channels.

  • And those channels can all be either reliable or unreliable.

  • In a game, you might want your state updates to be reliable,

  • but projectiles can be sent over an unreliable channel.

  • Security and congestion control is built right in.

  • The app gets this for free.

  • And we've tried to make developers lives easier by

  • keeping a similar API to WebSockets.

  • So that code written to use a WebSocket should work just as

  • well when coupled with a DataChannel.

  • So here's a simple usage of DataChannels.

  • We want to have two clients exchanging data.

  • They exchange session descriptions to get the peer

  • to peer link set up.

  • And then, we're ready to go.

  • We send the data.

  • And it gets sent over the internet using standard IETF

  • protocols, SCTP, Datagram TLS over UDP.

  • It goes through a [? NAS ?], it just works.

  • This is going to be a revolutionary technology.

  • And here's what this looks like in code.

  • It's really simple.

  • You just call on each side, create DataChannel, you

  • specify an identifier.

  • This identifier is what allows both channels to get connected

  • together in the middle because they're indicated by name.

  • And then, once it's connected, you just

  • call/send on one side.

  • And our message gets called on the other side, just like

  • WebSockets.

  • Now, I wish I could show this to you now.

  • But as I mentioned before, we're still finishing up the

  • details of the spec.

  • But expect to see this in Chrome in the near future.

  • So you can also imagine some more complicated

  • topologies for this.

  • If we want to distribute data between multiple peers, we can

  • create a mesh, where each endpoint is connected to each

  • other endpoint.

  • If you're creating like a multiplayer game, this is a

  • really easy way to get multiplayer functionality

  • without having to have a big server infrastructure.

  • But you can also imagine some other interesting things.

  • You create a graph.

  • And say you want to be able to send down a lot of data from

  • your service.

  • Instead of having to send the data n times by unicasting it

  • to all your clients, you can instead construct a tree, and

  • use peer to peer to push the data very efficient to all

  • your clients.

  • Since you control the application, you can have the

  • application take the data and it's distributed to other

  • peers that it might be connected to.

  • There will be some amazing things that will be created as

  • a result of this technology.

  • OK, so we went over a lot of stuff really quickly.

  • Let's review.

  • We're building real-time communication into the fabric

  • of the web, providing amazing new voice, video, and peer to

  • peer functionality in the open web platform, and enabling the

  • communications industry to move at web speed.

  • This is a really exciting time.

  • We're really excited on the team.

  • We can't wait to see the apps you guys are

  • going to build on this.

  • So MediaStreams are shipping in Chrome 21.

  • PeerConnection is in Chrome 20 behind a flag.

  • But we're working hard to try to stabilize it in

  • time for Chrome 22.

  • The DataChannel works is going to follow along after that.

  • And we expect to do this by the end of the year.

  • Opera is also shipping MediaStreams now.

  • And our friends at Mozilla, they tell us they think that

  • they get all this stuff done by the end of the year.

  • Now, for people using Internet Explorer, we've got WebRTC

  • running in ChromeFrame.

  • And it works great.

  • As we start to stabilize things, we're also going to

  • see stuff landing in mobile browsers.

  • And as I mentioned before, we have native versions of the

  • entire stack available for the app builders out there.

  • So here's our resident Icelandic team member, Tommy

  • Gunnarsson.

  • He's showing off AppRTC running here in IE, courtesy

  • of ChromeFrame.

  • So for more information about ChromeFrame you check it out

  • at google.com/chromeframe.

  • Now, incidentally, we might be thinking, well what is

  • Microsoft doing about supporting

  • this natively in IE?

  • Well, I don't know for sure.

  • But I saw a couple of WebRTC related job postings show up

  • on the Microsoft career site in the past week.

  • So I'm pretty sure they're investing

  • pretty heavily in this.

  • OK, so I'd like to show you one more demo, or two more

  • demos here of examples of what third-party developers are

  • doing with this technology.

  • So the first is an application called Twinsee.

  • The team there has created a WebRTC app that works on both

  • web and on mobile.

  • And I'm going to call them up now using the app

  • that they've built.

  • MALE SPEAKER: Hello.

  • JUSTIN UBERTI: Hey, guys.

  • You're live at Google I/O 2012.

  • MALE SPEAKER: Wow.

  • JUSTIN UBERTI: So tell me about this app that

  • you've built. .

  • MALE SPEAKER: OK so let me introduce ourselves.

  • So I'm [? Michel Gien, ?]

  • and I'm here with [? Christian Giacomo. ?]

  • And we founded Twinlife at the beginning of this year.

  • And the purpose of Twinlife is connecting generations.

  • So our focus right now is to take Android tablets and smart

  • TVs and make them usable by older persons, so they can

  • interact with their family, their children and

  • grandchildren.

  • So our first building block is this Twinsee service, which is

  • made of an Android application, using at the

  • native WebRTC APIs, which Christian

  • integrated into Android.

  • And web service, twinsee.net, to connect users, whether they

  • come from a Chrome browser, or whether they come from a

  • Twinsee application on Android tablet.

  • JUSTIN UBERTI: That's great.

  • It feels like you guys are right here in San

  • Francisco with us.

  • So when can I expect this to be available?

  • MALE SPEAKER: Twinsee will be available for public testing

  • on the Android Market in the August time frame.

  • So I'll show you here in the mirror.

  • You can see that this tablet we're using

  • right now is Asus Prime.

  • And so if you have any questions, contact us at

  • twinsee.net.

  • JUSTIN UBERTI: OK, that looks great, guys.

  • MALE SPEAKER: I hope you're have at Google I/O. I wish we

  • were there.

  • JUSTIN UBERTI: Looks great, guys.

  • Well, that's really exciting.

  • I'll let you guys get some sleep.

  • Talk to you later.

  • [APPLAUSE]

  • JUSTIN UBERTI: OK.

  • So the last thing I want to show, I know a ton of you are

  • using GitHub to host and share your code.

  • So that's why I'm really excited to introduce this next

  • app called GitTogether, which brings real-time communication

  • to the GitHub community.

  • Now, the guys who built this have been involved with WebRTC

  • since the very beginning.

  • Let's call them up now.

  • And they can tell you about how this works.

  • These guys have been working on this.

  • They're creating not just an application, but also a

  • JavaScript framework that allows a lot of

  • simplifications to be done for people who are WebRTC

  • developers.

  • So that's everything for WebRTC see today.

  • We covered a lot of stuff quickly.

  • [APPLAUSE]

  • JUSTIN UBERTI: Thank you.

  • Oh, also, the GitTogether is made by vline.com.

  • Also, check out the Chrome Developer sandbox.

  • We've got some stuff down there.

  • There's a Voxeo, who is an emergency response app being

  • built using WebRTC.

  • And we've also got a really cool WebRTC based game

  • called Who Am I?

  • MIT

  • Thank you all for coming.

  • I'll be happy to answer any questions that you might have.

  • Step up to the microphone, so the video can record it.

  • AUDIENCE: In a lot of your slides, you had a dotted line

  • between the two browsers on the bottom.

  • Is that an actual connection somehow.

  • I mean, if both of them are behind a net firewall, how do

  • you get the peer to peer communication to go?

  • Is there actually a server there that's--

  • JUSTIN UBERTI: So there's a technology called ICE.

  • And ICE is Interactive Connectivity Establishment.

  • And what it does is it basically finds all the IP

  • addresses that it can come up, your local address, the

  • address of your NAT or firewall, or an address that

  • could be hosted in a data center.

  • And it does interactive checks to figure out what is the best

  • path between the two peers to establish data.

  • In our experience with Google Talk, we find that in about

  • 90% of the cases, we can actually establish a peer to

  • peer link, even if both sides are behind NAT.

  • The rules of NAT are such that if we know the address of the

  • other person's NAT, we can still get that peer to peer

  • link going between two peers using UDP.

  • AUDIENCE: Thanks.

  • AUDIENCE: Hi.

  • Can you talk about codec support?

  • Because I know you guys have acquired GIPS, and with that

  • came iLBC and iSAC.

  • But are you going to do something like Opus support,

  • or something like that?

  • JUSTIN UBERTI: So this is all a big topic for the IETF.

  • But what we are planning support, assuming we can work

  • out all the licensing details, VP8 will be our open, royalty

  • free video codec.

  • And then, as far as all your codecs are concerned, we'll

  • support G.711 for legacy interoperability.

  • We'll support iSAC.

  • And we hope to support Opus, assuming that Microsoft can

  • help us out in the licensing front.

  • AUDIENCE: And can you talk about iLBC voice quality on an

  • Android platform?

  • Have you guys had good luck with it?

  • I mean, are you seeing good performance relative to a

  • general cell phone call?

  • JUSTIN UBERTI: We have the person who wrote iLBC here

  • sitting in the audience.

  • AUDIENCE: That guy, right there?

  • JUSTIN UBERTI: Yeah, that guy.

  • AUDIENCE: OK, I'll talk to him.

  • Thank you.

  • AUDIENCE: Hi.

  • Simple question, I saw on the first demo that you showed how

  • to use video.

  • Well, you didn't show about audio, but I guess audio is

  • also included.

  • Only on one to one conversation, is there a way

  • to make it broadcast?

  • For example, this show can be seen on the web page by

  • multiple users?

  • JUSTIN UBERTI: Yeah, so a PeerConnection creates a

  • connection between yourself and a remote peer.

  • And if you want to have a multi-way conversation,

  • there's a couple ways you can do this.

  • The first thing is you could have multiple PeerConnections

  • and establish a full mesh, like I show here.

  • If you have four participants, you establish three

  • PeerConnections, one of each remote participant.

  • This doesn't scale all the way up.

  • So one of the other things that you can do as you get to

  • be in a large conference, is actually have a central server

  • and create like a star topology, where the other

  • side, instead of being a browser, is actually a server.

  • And then using the WebRTC tools, you can create a server

  • that could do multi-party.

  • AUDIENCE: OK, I think maybe I asked you wrongly.

  • I'm only interested one party who is transmitting.

  • The other ones don't need to talk, only to listen.

  • So it's like UDP in that sense.

  • JUSTIN UBERTI: Right, right.

  • Sorry.

  • In that case, the other side wouldn't even have to call

  • getUserMedia.

  • So the side who calls getUserMedia can specify

  • whether it wants video and/or audio.

  • But you won't need to call getUserMedia at all.

  • So if you want to receive only, you just would not call

  • getUserMedia, and you wouldn't call AddStream on that side.

  • And then you would just play.

  • AUDIENCE: I see.

  • OK, thank you.

  • JUSTIN UBERTI: Sure.

  • AUDIENCE: So if you want to stream to the server and save

  • the recorded video, are there components or libraries that

  • are available?

  • JUSTIN UBERTI: So I mean, if you're familiar with media

  • processing, you can build these kind of servers using

  • the WebRTC components.

  • There is something in the WebRTC spec for an API called

  • Media Recorder.

  • It's missing a lot of detail right now.

  • So it's not being implemented.

  • But we expect, at some point in time, there will be an easy

  • way to do media recording.

  • For right now, the easiest way is to build a server, make a

  • PeerConnection to it.

  • And then you can then save it out to a file there.

  • AUDIENCE: So the component would be the C++ libraries

  • that you would bind into your server?

  • JUSTIN UBERTI: Yes.

  • AUDIENCE: I had a question about whether Screen Sharing

  • is still in consideration as a video source?

  • JUSTIN UBERTI: It absolutely is.

  • The question is whether Screen Sharing will be supported as a

  • video source.

  • And it's sort of one of these things where we definitely

  • want to support it, we have the technology to do it.

  • But in terms of making sure we get something out there, v1

  • will be just video only.

  • AUDIENCE: [INAUDIBLE].

  • JUSTIN UBERTI: You could also do it with camera drivers.

  • Although, the issue with camera drivers is that their

  • resolution will be artificially limited.

  • AUDIENCE: Do you have plans to integrate

  • with Server-Sent Events?

  • JUSTIN UBERTI: Server-Sent Events.

  • Are you specific about what you have in mind there?

  • AUDIENCE: Well, to get the session exchange pushed back

  • the answer.

  • JUSTIN UBERTI: I think I'll have to get back you on that.

  • I'm not sure I'm familiar enough with

  • the Server-Sent Events.

  • AUDIENCE: They're part of the [INAUDIBLE] working group

  • specifications.

  • JUSTIN UBERTI: We can talk afterwards.

  • AUDIENCE: Hi.

  • There will be any SIP integration in the future?

  • Any way to make a phone call using these API?

  • JUSTIN UBERTI: Yeah, so we actually have some demos--

  • I didn't show them today--

  • where you can actually make a phone call to the PSTN.

  • And there's a couple ways you can do it.

  • You can send JSON to your web server, and have the web

  • server then gateway that to SIP.

  • Or there's a product called sipML5--

  • sipml5.org--

  • where they're actually implementing a SIP stack

  • within the browser itself.

  • So it converts the session descriptions to SIP messages

  • right inside the web application.

  • So you can definitely do SIP calls using this technology.

  • AUDIENCE: Great.

  • And there will be an SDK for Android, or something?

  • JUSTIN UBERTI: Yeah, we have existing SDK.

  • If you go to WebRTC.org, you can download the code for

  • running this on Android.

  • AUDIENCE: Thank you very much.

  • JUSTIN UBERTI: Sure.

  • OK.

  • Thank you all for coming.

  • [APPLAUSE]

JUSTIN UBERTI: So what you all think of the Google Glass

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

B1 中級

谷歌I/O 2012 - WebRTC:HTML5中的實時音頻/視頻和P2P (Google I/O 2012 - WebRTC: Real-time Audio/Video and P2P in HTML5)

  • 25 4
    colin 發佈於 2021 年 01 月 14 日
影片單字