Noticed any differences when using Google’s Hangouts video chat lately? If you did, then you may be one of the lucky users who has already received an upgrade to 720p HD video. The company quietly started to roll out HD for Hangouts to a subset of its users in the last few weeks and hopes to complete the rollout soon. But the change isn’t just a quality upgrade – it’s part of a bigger move towards open standards that will eventually bring us video chat in the browser without the need for any plugins.
To enable HD, and prepare for this plugin-free future, Google quietly started to transition Hangouts from the H.264 video codec to VP8, an open and royalty-free video codec the company released back in 2010. Google’s Vice President of Engineering Chee Chew told me during a recent interview that the switchover from H.264 to VP8 should be more or less invisible to consumers, with some possibly noticing a little less choppiness. “It will be cleaner, better video,” Chew said.
Good move.
On a related note, whatever happened to Apple’s promise to make FaceTime an open standard?
Still no word from Google on opening Hangout protocol to enable federation? From the time they cut it off from XMPP all their direction went downhill openness wise. Switching codec is good and expected, but it still keeps it a closed garden without federation.
It essentially doesn’t matter with WebRTC and Cross Browser Communication.
Anyone can make a web application (or any other kind of application I suppose), that allows you to sign in with Google or any other service (Twitter, Facebook essentially anything that implementes OAuth 2) and you be able to video chat/voice chat/IM.
Edited 2013-08-28 16:09 UTC
So, no open code, but open codec and open API? I admit I’m a bit confused by the whole transition that is happening with Google Hangouts. If there’s an informational article I could read somewhere, I’d appreciate a link.
Tbh I wasn’t overly commenting about Google Hangouts.
The tech being used here, one can find quite a few examples of how to do the same thing with WebRTC.
https://developer.mozilla.org/en-US/docs/WebRTC/Peer-to-peer_communi…
Edited 2013-08-28 17:08 UTC
When I found out how easy it was (at least conceptually) to use WebRTC to do video conferencing across platforms, I was immediately thrilled at the prospect of being able to dump skype in favor of it by telling friends to visit my webpage instead. It actually worked strait away for me on both window and linux with firefox… however I tried it on android and I couldn’t get it to work under chrome or firefox.
Can anyone else get this video chat app working on android? Or iphone for that matter?
https://apprtc.appspot.com
Some of the code is still a bit new, it will take a few more releases to be great. And mobile browsers don’t always have the same support as the desktop browsers yet.
Make sure you’re using Chrome 29 on Android.
Anyone can make anything. It’s not the point. The point is that those things should be able to communicate with each other. WebRTC is a pipe, it doesn’t dictate any signalling protocol used through it. So anyone can make something that will never work with anything that someone else will make. That’s why there are actual protocols like XMPP, Jingle, SIP and etc. which enable interoperability.
http://www.webrtc.org/faq#TOC-Why-should-I-use-WebRTC-
Edited 2013-08-28 17:49 UTC
I know what WebRTC is. FFS. You are so tiring.
WebRTC and all the other goodness it brings lets any browser which supports it, whatever the OS and anyone that can write a bit of JavaScript and a Server side script make a communications service.
I honestly dunno what can be more open than that?
Edited 2013-08-28 17:59 UTC
So what? How does it help the interoperability if there is no agreed messaging and signalling protocol which is supposed to be built on top of WebRTC? It’s like saying that TCP/IP and UDP help building communication services. They do, but it’s what built on top of them matters. So going back to Hangouts, since their protocol is closed, they aren’t interoperable so the fact that they use WebRTC is completely irrelevant to the subject above.
Edited 2013-08-28 18:15 UTC
The API is provided by the browser, which is a w3c spec, all you do is a handshake and exchange a token.
Edited 2013-08-28 18:23 UTC
Yes, for the basic communication. TCP/IP sockets are also useful for building other stuff, you know. But serious messaging network requires a complex set of instruments. User identification, presence and so on. Those are all higher level protocols like XMPP. Hangouts implement their own, that’s the point. WebRTC is a lower level in this context and it doesn’t matter that it’s open for this issue.
Edited 2013-08-28 18:32 UTC
No, browser to browser communication has all of that.
http://www.html5rocks.com/en/tutorials/webrtc/basics/
It is all there. And I found that in a single google.
All the other stuff you mention you can either use existing services like I already said, or build you own.
And it is a hell of a lot simpler than XMPP.
Has all of what? Who cares whether it’s browser or a standalone client? They all need to interoperate. WebRTC is low level framework. It does not dictate messaging and signalling protocols.
Edited 2013-08-28 18:37 UTC
You are not reading, you are not even bothering to understand to understand what I originally said.
I am ending the conversation here, because you are being deliberately difficult.
Edited 2013-08-28 18:38 UTC
No, it’s you who aren’t reading. From the page you linked:
Here you have it. If developers implement different signalling, who cares if they use WebRTC, their solutions would be incompatible.
Which means you completely miss the point of what I was trying to say in the first place.
Anyone that is signed up with a service that uses 2 factor authentication, will be able to sign into any 3rd party service that anyone can build.
So it doesn’t matter if Google never support XMPP again (XML is overkill most of the time anyway), if you want to talk to someone on another service, you just use a service that supports sign-in with that service and google.
Or if you don’t want to use that, you can just put you name in and mail them the URL to your chat instance. With video and audio once the link is established the browser does the rest.
Edited 2013-08-28 19:06 UTC
How are you going to be notified that some user is on-line for example?
The browser raises an event to the server.
What protocol is used for that? How does the browser know how to “raise” such event? How would server interpret that connection and why should they understand each other?
This should also work with any other client which is not a browser by the way.
Edited 2013-08-28 19:41 UTC
Go away and build yourself using WebRTC and WebSockets and you will know. I am not explaining the whole web stack to you when it can be googled, and I already given you the information twice.
You are not explaining because you can’t explain it without saying “go implement your own signalling / messaging and you’ll know”. That was my point all along. Everyone will implement the heck differently, and have good luck connecting all those clients and servers with each other, while being very proud they all use WebRTC.
Edited 2013-08-28 19:44 UTC
So Kinesthetic learning is a bad idea. Got it.
Are you saying there is no point in having standard and commonly agreed on communication protocols?
Edited 2013-08-28 19:53 UTC
No. I’ve actually worked with the technology and I had skype like experience in my home office.
All I needed was socket.io (which isn’t a messaging protocol, it an abstraction over websockets) and a few other bits of JS to hook it all together.
Persisting JavaScript objects between node and the browser isn’t a message protocol.
Well you don’t know how the tech works.
It is irrelevant the message protocol because once it gets to the browser you deal with it using JavaScript. Existing Web-services fill in the rest of the gaps.
Here is an existing app as an example:
http://twelephone.com/
Edited 2013-08-28 19:59 UTC
You got it all wrong, since client can’t be restricted to the browser. If you tie your communication to browser only, the service is junk. The service should have a clear protocol defined, so the client can be built anywhere. In the browser (using WebSockets + WebRTC to route your protocol), as standalone client using whatever and etc. JavaScript should not be a requirement for building a service. It’s ridiculous.
Anything can implement web sockets, and pushing JavaScript objects or more likely JSON can be done to pretty much any programming language and platform pretty simply.
Again you lacking imagination and any clue as to what you are arguing about.
Edited 2013-08-28 20:22 UTC
JSON is not equal to JavaScript. I answered to your language above.
I said JavaScript Objects, I know they aren’t exactly the same. But it is trivial to convert between the two.
lucas_maximus,
“Well you don’t know how the tech works.
It is irrelevant the message protocol because once it gets to the browser you deal with it using JavaScript. Existing Web-services fill in the rest of the gaps.”
shmerl is actually right though, I think you are missing his point. It’s not enough that two solutions use WebRTC to be compatible. They actually have to use higher level messaging protocols that are not defined in the WebRTC spec. It’s not enough that they both use javascript.
webrtc doesn’t have a signaling protocol, maybe because otherwise companies like Microsoft/Skype and maybe Ericsson wouldn’t even get involved ?
It also makes it a lot more flexible, if you define the signaling protocol you would define the use cases too.
The point is, that in order to interoperate those protocols need to be compatible. If they aren’t, WebRTC helps nothing.
Okay – but where is the protocol coming from? How does client A using a bespoke protocol talk to client B with an implementation of XMPP and client C using legacy AIM? All over a WebRTC based solution. You have never explained how that would work, and I believe that is what Shmerl is asking. Having a low level transport is only part of the issue. TCP/IP doesn’t automatically give you HTTP out of the box. TCP/IP is WebRTC and HTTP (etc) is the chat protocol from what I can tell. Please explain how that works and we can all agree with you.
Yes, but how do you *find* the other users to chat with? Do you really expect everyone to send each other their current IP addresses and fire up their own hacked-together JavaScript pages at pre-appointed times to chat with each other? The API does not include presence notification, “ringing up” other people, chatting, etc. No one except extreme nerds are going to actually use the API in its “pure” form. This is why something like tying WebRTC together with XMPP would make a lot of sense…
All it requires is a webpage and the appropriate server side technology
http://www.html5rocks.com/en/tutorials/webrtc/basics/
You don’t need webpages for communication. You are missing some important points here. You need protocols for them.
Communicating through the browser would require a web page since that’s how the browser works of course. WebRTC is not limited to browsers though.
Edited 2013-08-28 18:39 UTC
You are an idiot.
The link explains exactly what is involved and at no point did I say that you only needed a web page.
See above. WebRTC is not a replacement for XMPP/Jingle, SIP and so on.
Well it will be, because nobody will want to implement them when there is a simpler alternative available, which requires a few JS functions and some servers sitting somewhere and they can build whatever the f–k they want on top of it.
Edited 2013-08-28 18:55 UTC
You still didn’t explain how it is an alternative while being simple. The page you linked doesn’t say that either.
Well you lack imagination then.
Maybe you shouldn’t be so quick to call other people idiots. GP is absolutely right. On the very page you yourself linked to, it states in black and white:
He is missing the bigger picture.
Anyone can make a service, where you can just sign in with an existing account such a google account or a facebook account and once that is done you, P2P browser communication is a simple to implement.
It couldn’t be done without plugins before WebRTC.
It essentially makes the discussion point about company X or Y supporting this message protocol or that redundant, because once the initial handshakes are done … everything is left the the JS APIs on each peers browser.
Edited 2013-08-28 19:16 UTC
But you are missing the point. All that is wonderful, but you will *still* need an underlying protocol to make it work, which leads you exactly back to square one. Without an implementation of a common protocol, the tech is about as useful as implementing the same functionality the old school way. You still need to do a butt load of development to implement a protocol to carry your chat messaging in such a way that the other users on the system can actually do something useful with it. The handshake and transport are fairly trivial in comparison to creating a robust and reliable chat/video protocol….
No I am not. I actually built something that is like skype.
Try it, it is just literally just setting the src of the video/audio tag, a bit of session management and that is about it.
All the hard work has been done by other people you are literally just passing JSON to the server and client and back, and you have code that responds to those events.
It is soooo simple …
Edited 2013-08-30 09:55 UTC
If you support SSO via Twitter/FB you can use the tokens to enumerate the users friends. Probably will take some persisted state to cross reference between friends on those networks and friends on the service to see which are participants.
You don’t seem to understand the point. Have you ever developed video chat app with WebRTC? I have. That handshake (offer/answer) and exchanging ICE candidates things should go through some kind medium such as ajax, web socket or else, and WebRTC is neutral to that medium. It does not define what to use nor it does have such medium built into WebRTC specifications. As such each video chat app using WebRTC could implement differently from each others. If the implementation of that part is closed, Hangouts cannot be inter-operatable with others unless it is reverse-engineered. (and Google can change the implementation as their will and it then will be broken.)
My point is that does it matter when you can easily implement “sign-in with x” and build you own site that interoperates with other social media sites?
XMPP is great, but I also think the WebRTC guys and gals might be taking a slightly different approach.
They want to have flexibility in how WebRTC is used, take Cromecast, it used WebRTC screensharing.
How would the model of XMPP apply to Chromecast ? Not so well I think.
A lot of work is not done with WebRTC.
They are actually now busy connecting the “identity assertions” to the encrypted media (audo, video, data):
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07
That is, I know, a different approach to XMPP.
But their goal is to support direct P2P media. It should eventually be possible so that your webbrowser can send the audio directly to a VoIP-phone.
So they are trying to standardize something above WebRTC? That’s good, but it’s nowhere standard yet.
Maybe you should think of WebRTC more of a framework of protocols that can be used to build other things.
People are using XMPP and SIP with WebRTC, that works.
VoIP phones probably less good, because most VoIP phones don’t support proper encryption and WebRTC only supports encrypted transport (it is probably a good thing to put improvement above compatibility).
But WebRTC itself does not define anything.
It is to bad Google Hangouts does not support XMPP anymore.
The real problem is of course that Google doesn’t say why they did it, they probably have a plan.
My guess is some product or service they want to announce. Or use of Google Hangouts we haven’t considered yet. Something like Google Helpouts maybe ?
Edited 2013-08-29 15:40 UTC
That’s exactly how I view it and it was my point above which lucas_maximus for some reason failed to understand. WebRTC itself doesn’t guarantee the interoperability of services which use it. Its’ the higher level protocols that do. And since those are closed in the case of Hangouts, they aren’t interoperable.
Edited 2013-08-29 20:06 UTC
The next question we would all like to know, but have no answer for yet: will it stay closed ?
But also: will it matter ?
Now that WebRTC exists and I think federation will be created on top, even with a standard…
Maybe a federated solution will win the market, even if Google’s solution doesn’t support it (in which case they’ll be left out).
Edited 2013-08-29 20:21 UTC
I’d be careful with predicting such things. XMPP case demonstrated that having a standard doesn’t guaranty the interoperability with various closed services without them voluntarily opening up to it. Why would WebRTC based stack work any better?
Edited 2013-08-30 00:25 UTC
shmerl,
“I’d be careful with predicting such things. XMPP case demonstrated that having a standard doesn’t guaranty the interoperability with various closed services without them voluntarily opening up to it. Why would WebRTC based stack work any better?”
That’s the trouble, often times companies aren’t all that fond of standards and interoperability. It’s a good example where business interests and consumer interests are contradictory. If a product is 100% compatible with open standards, then the vendor looses the ability to vendor-lock customers. Strong standards also diminish their ability to differentiate their service from competitors who’ve also adopted the same standards.
But it does support XMPP still (I use it as such, from Miranda IM or original win32 GoogleTalk, to chat with Hagouts-using buddies), just not federation.
Sorry for misrepresenting the facts and thanks for clarifying it.
Meh, who cares anymore? At this point, all you can really do is tell Google (and the NSA) to go fuck themselves and support real open standards yourself by creating an account on a Jabber server somewhere. Preferably one that is not on U.S. soil if you care even the slightest about Edward Snowden’s revelations and the U.S. government’s blatant violations of its own citizens’ privacy, as well as people in other countries. I would personally avoid servers located in Britain also, since they’re piggybacking off the NSA and have their nose firmly up the U.S. government’s ass.
And to prevent your communications from being intercepted by the NSA while jumping around servers, it would be a good idea to avoid XMPP’s federation completely by having people you know subscribe to the same non-U.S.-based XMPP service. As great as federation is, if you really care about your privacy it seems that privacy concerns brought upon by the NSA are forcing us to pick between independence of one service by using federation, or being tied to one service for privacy. It’s pretty sad that it effectively comes down to this.
You could always chat “off-the-record,” but have fun explaining to people why they should go through what they will undoubtedly perceive as unnecessary trouble. If they’re anything like the typical people I know, have fun even getting them to sign up for a new account elsewhere and setting up an XMPP client.
OTR works perfectly fine with federation and it’s not hard to set up. It doesn’t work with MUC though (multi user chat), and it’s a big downside.
I know that OTR works with federation, but the problem is convincing people to go through the extra trouble to use it. Most people won’t.
People who care about privacy will. Those who don’t care aren’t using XMPP probably to begin with. They use Skype and other such junk.
However there is a glaring lack of proper encryption support (OTR, ZRTP etc.) even in many XMPP clients. Especially on mobile. I think it’s a much bigger barrier than people not willing to configure things.
Edited 2013-08-28 20:52 UTC
Atleast webrtc uses proper DTLS encryption, that is a lot better than most VoIP solutions and Skype and all the other crap.
so… we close our protocol and advertise app with another ‘open’ standard… double standards at big-g?
It seems to me that Google does really not like third parties messing with “non final” products.
I mean, knowing that Hangouts is eventually going WebRTC, ditching Talk’s standard XMPP sounds a lot like the recent Chromecast issue: “we are leaving you out for now, but come back later”.
Aren’t most Google products “Non final” (beta)
WebRTC is not a replacement for XMPP. It’s a lower level framework.
Edited 2013-08-28 17:47 UTC
Did you know Chromecast is also using WebRTC ?
It’s actually a form of WebRTC screensharing.
From my experience using a Nexus 7 and a Nexus 4 for doing Google+ Hangouts the video has been terrible compared to Apple’s FaceTime.
Don’t know if this is due to the cameras in use or the software but the audio / video on FaceTime always looks better.
This could have many reasons.
First of all Apple controls all parts of the stack, this always makes it easier to get something on the market.
Second, WebRTC is trying to create a standard, which takes time and effort.
WebRTC is still new and your call might have used VP8 without hardware acceleration. Who knows.
I hear recent Nexus devices have hardware encoders and decoders for VP8.
Until they fix the presence notification features (i.e., let me actually see a list of everyone who is logged in), I refuse to use Hangouts. How a company like Google, who otherwise gets so much right, could build something supposedly better and in the process completely remove core functionality like this, then proceed not to fix it for a half year despite users’ almost universal outcry about it (just take a look at the Play Store page: https://play.google.com/store/apps/details?id=com.google.android.tal…) is beyond me.
Thank god for the move towards WebRTC. Getting rid of the use of god awful show stopper plugins so the service is available to a much wider audience is a good move.
Yup. I could never get the Hangout plugin to work from my office, even in Chrome. Apparently the plugin and the corporate firewall disagreed on the details. Moving towards WebRTC is a good thing, although I’m sure someone will be along soon to tell me how “evil” they are for doing it, or something.
On a related note, whatever happened to Apple’s promise to make FaceTime an open standard?
I guess the patent problems Apple has may have something to do with them not keeping that promise:
http://arstechnica.com/tech-policy/2013/08/report-after-patent-loss…