Google Hangouts and the Video Conundrum: Vidyo Should be Worried

Codec implementations have been commoditized. The time has come to move on to a new gig.

[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]

I come from the video conferencing market. Lived it for over 10 years. During that time, I’ve seen most vendors focus on the quality of their codecs – be it video or voice – the latencies, the resilience to packet loss, the feeds and speeds of their codecs. Those were fun times.

Today? It has been commoditized.

  • Want a picture format? There’s Google’s new WebP, which is better than JPEG, GIF and PNG – it replaces them all
  • Need audio? Go for Opus. It trumps MP3, G.722, AMR with no royalties attached
  • Video you say? There’s VP8 and soon VP9. Source available online. For free

Innovation, differentiation and creativity cannot come from the codec any longer – at least not on its own.

Google launched Hangouts last week during their I/O event with much fanfare. I will be writing about it next week – still need to wrap my head around it. But until then, I wanted to touch something interesting about it.

When Hangouts launched, people tried to understand if it uses or doesn’t use WebRTC. If Google have finally made the move and decided to dogfood their own technology. Up until now, Google Talk, the old service, have used a video codec known as H.264/SVC, with an implementation from one of the enterprise video conferencing companies – Vidyo. Vidyo were rather quick to come out with a blog post, explaining to their customers their strong partnership with Google – and implying it still uses Vidyo:

The truth is this was just an editorial oversight and the media technology in Google+ Hangouts did not change. Our partnership remains as strong as ever, and frankly, we couldn’t be happier.

Did Google+ Hangouts change? I don’t know. It probably does use Vidyo’s technology.

201305-Hangouts-tech

Does it use WebRTC? I don’t know. But why does this matter?

My own belief? Google didn’t push WebRTC into Hangouts simply because it was a bit too soon. They will do that in a future release.

Vidyo’s main edge in its market (which is enterprise video conferencing) is in their SVC codec; but this edge is eroding with time. As far as I can tell, Vidyo still runs and strategizes the same way as the rest of its market, and that is going to be heavily disrupted with WebRTC. But somehow, its competitors are going in the same trajectory – at least from publicly known information.

So yes. Hangouts might still use Vidyo’s codec. But that should not increase or reduce a customer’s confidence in Vidyo.

Tags: , , , , , , , , , , ,

Liked this post?

Share it!

Never miss a post!

Or just grab the RSS feed!

Comments

  1. Your thesis is not correct. Vidyo’s advantage is not H.264/SVC, it’s their VidyoRouter server side technology. Anyone can implement a codec. The hard part is the back end server architecture.

    • Tsahi Levent-Levi says:

      That may well be true, but it is still tightly coupled with the reasoning behind investing in SVC.

      I am not sure if Google have licensed that technology or not, but let’s at least agree that if Google shifts to VP9 instead of Vidyo’s codec, they will not keep any router technology from Vidyo either.

      That said, I don’t see any of it matter to a Vidyo customer.

      • I don’t think any of us can speculate on what goes on in Google’s and Vidyo’s minds. I’m sure they are going to do whatever makes the most sense and gives the end user the best experience. Without knowing exactly what Google did or did not license from Vidyo I think it’s silly to speculate on what they’re going to do in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">