Updated July 9, 2014
So Google really has dropped the Vidyo plugin for Hangouts as it switches over to its VP8 video codec. It’s still not on WebRTC, although it’s surely getting there. On dev versions of Chrome, Google Hangouts is now plugin-less.
In my article on VSee vs. Google+ Hangouts, I mentioned that Google had used Vidyo’s technology at one point to power their real-time video products (such as Hangouts and GoogleTalk video chat). However, they eventually dropped Vidyo because in the end, Vidyo is just too complicated and requires too much infrastructure. Meanwhile, the direction Google is heading is a browser-based experience with WebRTC. In fact, this is the trend for video conferencing in general. Here’s my quick summary of where video conferencing is going.
Three Generations of Video Conferencing Architecture
First generation: products such as Polycom and Tandberg (+) These products made video quality good enough for high quality conversations for the first time in history at a reasonable price (for IT departments). Before Polycom and Tandberg, your choices were expensive hardware such as PictureTel ($100K to $200K) or software such as CUseeMe. Software-based video quality was sufficiently poor that it was mainly a novelty and didn’t have market adoption. Polycom and Tandberg offered hardware in the $10K to 30K range, a cost low enough for IT to purchase for conference rooms. Polycom and Tandberg became billion dollar companies. (-) A downside of the first generation products is that dedicated hardware is required for the end point.
Second generation: products such as Vidyo and Blue Jeans Network. (+) These products were able to replace the hardware endpoint with software-only endpoints, and still achieve amazing video quality. Furthermore, these software-only solutions are able to reduce the price points of HD video to only a few dollars per month – thus making high quality video affordable to most enterprises. (-) A downside of second generation products is the complicated server infrastructure. For both Vidyo and Blue Jeans, video must first flow through a video server.
Third generation: products such as Skype, Tango, WebRTC/OpenTok, Hangouts, and VSee. (+) Third generation products eliminate the server infrastructure by using peer-to-peer video streaming. They will also be web-based, so making a call is as simple as clicking on a button on a web page. Rising star, WebRTC, allows you to build video right into the browser. (-) The problem is WebRTC is only supported by browsers Google Chrome and Opera. Since Google does not control 100% of the browser marketing share the adoption of WebRTC still remains to be seen, (Note: We list OpenTok as WebRTC because even though it currently uses Flash, it will be using WebRTC in the future.)
VSee, The WebRTC Alternative
An alternative to WebRTC is VSee. VSee’s simple web API makes web calling trivial. It does not require administrator permission to run (unlike Skype), thus a simple browser plugin is all that is required to start a VSee video call. Furthermore, VSee improves on the classic P2P approach of Skype and WebRTC by enforcing end-to-end encryption at 256-bit AES. This not only makes VSee perfect for telemedicine, but also makes all VSee conversations private and off-the-record by default.
Related articles
- The Technology Behind Google+ Hangouts (GigaOm)
- Meetings.io Acquisition Signals Start of WebRTC Era? (VSee blog)
- VSee vs. OpenTok (VSee)
Follow us on Twitter (@VSee) and Like us on Facebook to hear about the latest from VSee!
Will you guys use Opus, too, soon? And if not, why not?
Very nice Milton!
Hi George! We’re definitely very interested in audio quality, and it’s likely we’ll have ultra wide band audio via either Opus or something similar by next year.
(For those who don’t know, Opus is a high quality, open source audio codec.)
Unfortunately, your article is just plain wrong. Google has not “dropped” Vidyo, and Google Hangouts are still powered by Vidyo H.264-SVC. It will be quite a while until Google changes from that solution to a webRTC based infrastructure mostly because the semantics around multi-point conferencing for webRTC are still being hashed out. I wouldn’t expect a changeover until webRTC has a defined multi-point solution and H.265 has been rolled out in appliance chips.
Reinforcing what Jon Steer wrote, Google has not “dropped Vidyo”, and continues to use their technology inside both Gmail Voice and Video Chat and Google+ Hangouts. WebRTC is still in its early days, and while good enough for simple 2-way video calls, has a long way to go before it could effectively handle video conferences with many participants. At least, not without utilizing a server infrastructure of some kind.
John is right, there is no support for multi-point in WebRTC standard at the moment, it’s mostly a client side technology. So every vendor, who plan to support WebRTC, will have it’s own server-based multi-point implementation. Hopefully some WebRTC client apps will have the ability to connect to multi-point servers made by other vendors.
By the way Skype, Tango, OpenTok and Hangouts aren’t p2p-based, they all use client-server infrastructure. P2p videoconferencing through the Internet is too unpredictable and complicated to have commercial success. Nevertheless there are some vendors who use p2p within LAN/VPN for video conferencing, but they have some serious limitations regarding for example the number of participants in a multi-point conference.
I thought Skype was known for being p2p…at least at some point in its career. It’s Wikipedia entry currently reads “Unlike most other VoIP services, Skype is a hybrid peer-to-peer and client–server system. It makes use of background processing on computers running Skype software. Skype’s original proposed name (Sky Peer-to-Peer) reflects this fact.” So it seems to be partially p2p. A Skype blog entry on its architectures also suggests this, “Skype to Skype calls do not flow through our data centres and the “supernodes” are not involved in passing media (audio or video) between Skype clients.”
I appreciate your idea.
WebRTC may be the future of solution to Video and Voice Chat, even though its development is a little delayed.
Vidyo’s technology has been used by Google for a long time, but this company has not been acquired by Google, which is a little thought-provoking.
I wonder if Milton will do some fact checking and write a retraction: http://venturebeat.com/2013/08/28/webrtc-gets-a-boost-google-taps-vidyo-to-build-better-web-native-video/
Thx, Joey for pointing out the error. Milton already wrote a correction post here.
In the article you say: “Third generation products eliminate the server infrastructure by using peer-to-peer video streaming”. Although a WebRTC session can be Peer-to-Peer, it still requires a minimum of a STUN/TURN server to establish a connection over NAT. Any communications solution that does more than just setup anonymous peer-to-peer connections is going to require servers for authentication, presence awareness, authorization, call logging at a minimum.
WebRTC by itself is not a Video Conferencing or UC solution, so statements like this just add to the confusion by saying that servers can be “eliminated”. Even if you adopt the WebRTC framework, there still is going to be a need for servers, cloud services, or services like VSee, OpenTok, VidYo and many other Unified Communications solutions.
Dear Jim,
really appreciate your clarification. A lot of people ask us about webRTC, and almost all of them are coming from the perspective of webRTC as the in-browser video conference system; where it is a complete system (like how OpenTok, AddLive, etc operates).
one key aspect is if the video has to go through a server or not; and if any servers have access to the raw unencrypted video stream. this is where the exact server architecture has a big impact on performance and security, and why I believe the newer/future generations of video services will abandon the Vidyo/Cisco approach.