Blog Post

Google sticks with VP8, opposes Cisco’s push to make H.264 the default codec for WebRTC

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

There goes that plan to unite the industry behind one video single codec: Google (S GOOG) intends to stick with VP8 as its default codec for real-time communication, even after Cisco (s CSCO) won support from Mozilla in a last-minute push to get everyone to adopt H.264.

Earlier on Wednesday, Cisco announced that it was going to provide third-party developers with a freely usable version of H.264, with Cisco paying any licensing costs. The first major project to make use of Cisco’s H.264 will be Mozilla’s Firefox.

The announcement came just a week before the Internet Engineering Task Force is meeting in Vancouver to decide which codec should become part of a new standard dubbed WebRTC that promises to bring interoperable voice and video chat to browsers and apps on all devices.

Google is a major proponent of WebRTC, but it has argued against using H.264, and instead proposed to use its own, license-free VP8 video codec. Cisco’s new initiative didn’t do anything to change Google’s position, with a spokesperson telling us:

“We continue to believe that open platforms should encourage open and royalty free technology. There is strong industry momentum behind the open, royalty free VP8 video format. We hope that the IETF community will come together in voting against royalty encumbered technology as they slow down the pace of innovation on the web and on the internet.”

However, that position seems increasingly isolated. Monty Montgomery, an influential open codec developer who recently joined Mozilla to work on a next-generation video codec called Daala, said Wednesday in a blog post that it may be time to move on:

“Let’s state the obvious with respect to VP8 vs H.264: We lost, and we’re admitting defeat. Cisco is providing a path for orderly retreat that leaves supporters of an open web in a strong enough position to face the next battle, so we’re taking it.”

He went on to argue that Cisco’s H.264 deal may be far from ideal, but that time may be better spent working on next-generation codecs and the licensing issues that will once again come up with these codecs:

“H.264 is already considered ‘on the way out’ by MPEG, and today’s announcement doesn’t address any licensing issues surrounding the next generation of video codecs. We’ve merely kicked the can down the road and set a dangerous precedent for next time around. And there will be a next time around. So, we’re focusing on being ready.”

9 Responses to “Google sticks with VP8, opposes Cisco’s push to make H.264 the default codec for WebRTC”

  1. I should probably post this to the newsgroup. Why does WebRTC need to define a codec at all? I could see recommendations on protocol, say RTP/RTSP, but what purpose does defining a codec serve?

  2. TheBasicMind

    Google, pushing forward with VP8 after this, indicates to me they are more interested in a destructive strategy and and finding ways to damage e.g, the power efficiency and convenience of competitor (read in the main iOS) devices than working for interoperability.

    This is the company that criticises software patents but only when they exist in an arbitrary magic bubble in space and time known as an end node or client device. When they relate to a centralised control point (read server) under their control, they, apparently,mexist in a different magic bubble and are ok. Indeed their business and vast majority of their revenues are built on them (ad-words patents). Funny how they remain silent about *those* software patents.

    But here’s the ugly truth, Google only beat the Open Source “free the source code” drum when it serves their purposes of getting as many client devices dependent upon and monopolised by their central, highly proprietary, CLOSED, centralised database driven services as possible.

    • Actually Cisco’s announcement changes nothing. H264 is still patent encumbered and Cisco’s offering is not open source or available on all platforms. They are offering a plugin similar to Flash Player. You know what? Flash Player already exists and pays for royalty on H264. We are trying to move towards a web standard where such proprietary players are not needed.

      • WaltFrench

        Dunno where you’re getting your information, but it sounds utterly, intentionally false.

        Here’s a clip from the OpenH264.Org page:

        Cisco is announcing today that we will take our H.264 implementation, and open source it under BSD license terms. Development and maintenance will be overseen by a board from industry and the open source community. Furthermore, we will provide a binary form suitable for inclusion in applications across a number of different operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module available for download from the Internet. We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.

        At this time, the source code download button is marked, “Coming Soon.”

        As of this announcement, anybody can implement the h.264 player without any royalty whatsoever (as Cisco has picked up the cost). The source, and well-defined rights to it, is open.

        (Yes, they ARE ALSO offering a binary as Adobe does, but as open source, it can be inspected and modified, which Adobe explicitly does NOT allow.)

        Go right ahead and “move” to a world where “proprietary players are not needed.” Presumably, that’d exclude players such as VP8 for which Google has merely paid the license fees for some embedded patents, and those which are being sued for infringing non-Google IP. Be sure to get back to us when you reach the Promised Land!

        • E.F.Gantry

          You didn’t prove anyone false, as they didn’t state that it wouldn’t be ostensibly “free” to those who chose to use cisco’s licensed version. The codec is still not free, rather cisco is footing that bill. A reasonable person might then ask “why would they do that?” and a reasonable person might answer “probably not out of the kindness of their hearts”. Cisco has self-serving reasons to establish that codec as the fallback, and they are well understood. Mozilla as well, and Google’s position is also and of course self-serving. So to single any one of them out for praise or criticism is ridiculous. There is no genuine, testable implement of “open source anything” in the universe of pay-to-play internet carriage. And as long as there are industry “task force”‘s comprised of big $$ players who’ve tasked “the industry” (themselves) with “agreeing upon” reductive practices like this, the result will always be one of exclusion and literally the antithesis of the concept of open source and democratized common carriage access for all and free knowledge. On an internet universe that requires us to pay for access, nothing is truly free or open, and no company is operating exclusively or even mostly for the benefit of those outside if their provenance. To think so is naive as well as supportive and collaborative of the pay system. They WANT you to think pro-open-source.

        • Nick is right, that changes little. We *have* free and open source implementations of h.264 (specifically x.264), which are already performant, highly tunable, and widely deployed in the open-source world. Cisco does not disclose the terms of the MPEG-LA license they purchased, so effectively, a contributor has no idea what parts of their h.264 module they can use or what they can change in their own use of it, and still qualify for protection from patent infringement, vis a vis transfer of the MPEG-LA license.

          Further, the only statement we’ve seen from a Cisco representative on the matter comes from Rowan Trollope, head of Collaboration team:
          “We will be paying the royalties for all downloads of the binary distribution of this open source component, which makes it free for any browser to include in their implementation.”

          My reading of the matter is that that they will pay licensing on the binary, and release the code. What an enterprise chooses to do with the code may not be. Hence, innovation is stifled and we’re back to square one. I hate to say it, but I’m with Google on this one. What if Cisco chooses not to release a FreeBSD binary? A Linux binary? What if they choose to discontinue support? Then we have an unlicensed community solution which an innovator is not permitted to integrate into a commercial appliance without securing their own licensing with MPEG-LA.

      • No, it changes a great deal. There is an awful lot of deployed H.264 out there, in Cisco equipment, in Microsoft’s Lync soft clients and in many mobile chipsets. By allowing that to be readily accessible to WebRTC endpoints — without the need for costly VP8-to-H.264 transcoding — enterprises can more easily extend their communications infrastructure across the web and mobile devices.

        I will readily admit that using a patent-encumbered video codec is not ideal. But we don’t live in an ideal world, and Cisco has just removed a substantial barrier to WebRTC adoption.

  3. “We hope that the IETF community will come together in voting against royalty encumbered technology” is an interesting thing to say, and it tells me that the spokesperson involved isn’t very knowledgeable about the issue.

    The “Tao of the IETF” document is considered pretty much the first place anyone should go to find out about the way the IETF works. While this sentiment appears in several places, the least ambiguous quote on the topic is: “Another aspect of [IETF] Working Groups that confounds many people is the fact that there is no formal voting.”

    In fact, if we simply voted on issues in the IETF, this MTI codec mess could have been put to rest a long time ago.

    Something that’s also being widely misinterpreted here is the fact that we’re only selecting the one “emergency backup” codec that is mandatory to implement. WebRTC inherently includes codec negotiation. The idea behind an MTI is to find some video codec — it can even be pretty crappy — but *something* that will prevent a complete and utter failure to establish video. If you have a better codec in common with the other end, that will be used instead.

    The only — ONLY — purpose of an MTI codec is to provide a fallback “codec of last resort.” It’s not a recommendation, it’s not an endorsement. It’s a hedge against complete failure to set up video. Nothing else.

  4. hundoman

    It is all about H.265 or HEVC as this is the future and will be built into the ATSC 3.0 standard when it comes out for an all IP based broadcast distribution in the United States.

    You can push much higher resolution and quality video with HEVC in smaller pipes than you can with H.264 which is the current standard today.