Linked by Thom Holwerda on Wed 28th Aug 2013 15:43 UTC

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?

Thread beginning with comment 570822
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[11]: Comment by shmerl
by lucas_maximus on Wed 28th Aug 2013 18:54 UTC in reply to "RE[10]: Comment by shmerl"
Member since:

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

Reply Parent Score: 3

RE[12]: Comment by shmerl
by shmerl on Wed 28th Aug 2013 19:01 in reply to "RE[11]: Comment by shmerl"
shmerl Member since:

You still didn't explain how it is an alternative while being simple. The page you linked doesn't say that either.

Reply Parent Score: 3

RE[13]: Comment by shmerl
by lucas_maximus on Wed 28th Aug 2013 19:39 in reply to "RE[12]: Comment by shmerl"
lucas_maximus Member since:

Well you lack imagination then.

Reply Parent Score: 2

RE[12]: Comment by shmerl
by Moochman on Wed 28th Aug 2013 19:03 in reply to "RE[11]: Comment by shmerl"
Moochman Member since:

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:

WebRTC uses RTCPeerConnection to communicate streaming data between browsers (aka peers), but also needs a mechanism to coordinate communication and to send control messages, a process known as signaling. Signaling methods and protocols are not specified by WebRTC: signaling is not part of the RTCPeerConnection API.

Instead, WebRTC app developers can choose whatever messaging protocol they prefer, such as SIP or XMPP, and any appropriate duplex (two-way) communication channel. The example uses XHR and the Channel API as the signaling mechanism. The codelab we built uses running on a Node server.

Signaling is used to exchange three types of information.

Session control messages: to initialize or close communication and report errors.
Network configuration: to the outside world, what's my computer's IP address and port?
Media capabilities: what codecs and resolutions can be handled by my browser and the browser it wants to communicate with?

The exchange of information via signaling must have completed successfully before peer-to-peer streaming can begin.

Reply Parent Score: 5

RE[13]: Comment by shmerl
by lucas_maximus on Wed 28th Aug 2013 19:14 in reply to "RE[12]: Comment by shmerl"
lucas_maximus Member since:

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

Reply Parent Score: 3