Thoughts About Cisco Open Sourcing H.264 and the WebRTC Angle

Cisco’s announcement about open sourcing H.264 left me more worried than I was last week.

[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.]

It has been two days since the dramatic announcement of Cisco and Mozilla. The gist of it?

Cisco took upon itself the licensing costs of H.264 from MPEG-LA and open sourced its own implementation of H.264 in the process. This paves the way for royalty free H.264 solutions, specifically in WebRTC.

The timing can’t be any better – right before the discussions at the IETF on the mandatory codec selection for WebRTC. And if it isn’t apparent to you by now, this whole charade about VP8 versus H.264 technical superiority – at the end of the day it is ONLY about business:

Codec wars

I was asked what is my opinion about this move. While I can’t really say I have one in such a short time, here are a few thoughts around it – no particular order or censor – consider it a mind-dump.

  • Cisco is trying to out-social Google. They did that by taking the hip approach of “opening up” conversation on Twitter with a hashtag and a scheduled timeframe. To me this was a way to let people vent instead of writing analysis posts. Nice move, but nothing more. The tweet-stream included no real beef inside it – something that is hard to achieve at 140 character lengths at a speed of 10 tweets per second
  • Up until now, Cisco was a non-player in WebRTC. They talked about it, but did nothing more than that publicly. This is a substantial move. Question is what is the motive and where are the products?
  • WebRTC now as another sugar daddy, and it is different than Google. Will they end up tearing the whole concept and “movement” apart in the process or will they find the way to cooperate?
  • Mozilla explains the flow and reasoning of adding H.264 to their browser. This added complexity of downloading modules on the fly from third parties when needed is nice, but doesn’t strike me like the right combination. Can’t explain why
  • And does Mozilla’s support of openH264 means the abandonment of VP8? There’s nothing in that blog post that indicate either way. Might Mozilla be using that as leverage against Google on some other issues, or are they just trying to dance at both weddings?
  • Apple and Microsoft are losing the initiative on this one. Will support for H.264 bring them into the fold and get them to embrace WebRTC? I don’t think so – doesn’t seem like the real reason for their feet-dragging act is the video codec
  • Where does this leave us with SVC? It isn’t part of the royalty payment Cisco is doing, so I guess multipoint as well as network resiliency were left for those with money in their pockets
  • H.264 winning this round means H.265 instead of VP9 in the next
  • And what about H.265? Will someone finance its royalties for us all, or is this a way to get us back on track to the patented and royalty paying video coding realm? To that end, are we selling our royalty free future for the sake of interoperability in the present?
  • Can this pave the way for faster adoption in mobile devices? Maybe. Not sure how H.264 encoders on mobile fair with RTC type use casesx
  • Transcoding is an inevitability. It won’t be required in some use cases, but in others you can’t go around it
  • Might Cisco have another video codec implementation? They probably do. Did they license the Tanberg video codec, the original one from their telepresence systems, the one on their VT Advantage soft client? Will they keep to themselves a higher end implementation?
  • What is a BSD license on a codec worth if patents must be paid when modifying the source code?
  • If I compile the openH264 code on my own, is Cisco covering me? If I use a different build environment than Cisco’s? Different compilation options? Different compiler? What about if I port it? Use it in an embedded system?
  • With VP8, vendors had access to the code of the codec. They could have changed it, modified its rate control or any other aspect of it – it fits well into server side environments or embedded devices. Can this be done with openH264? What happens to patents and licensing in such a case?
  • Encoders are heuristic in nature – the implementer decides what to focus on – be it low complexity, low latency, high quality, etc. The Cisco codec chose a trajectory and we now should all follow. Or pay for its patents. Different than doing the same over VP8
  • What happens if (and when) some nasty patent holder not in MPEG-LA comes knocking on the door of a successful WebRTC implementer? How is that different than Nokia asserting its H.264 related patents over Google when it comes to VP8?
  • Are these recent MPEG-LA deals with Google and Cisco indicating the end of the road for H.264? Can we consider it as a generic drug in terms of the drug industry? One which everyone can copy and commoditize?
  • Will that impede the adoption of Opus, now that the road is cleared for renegotiation of which codecs should be mandatory in WebRTC?
  • There’s no room for 2 mandatory codecs

Some other interesting posts about this topic:

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

Liked this post?

Share it!

Never miss a post!

Or just grab the RSS feed!

Comments

  1. I think saying Cisco is a non-player would be at least an understatement. Maybe even a slap in the face. Don’t mistake not releasing a product as not being involved.

    Cullen Jennings, a Ciscso fellow, is one of the chairs of the RTCWeb IETF Working Group and one of the authors at the W3C for the WebRTC spec.

    At the IETF RTCWeb workgroup I would say he’s the most ‘visible’ of the chairs, as he leads a lot of the RTCWeb workgroup meetings.

    He also does talks and panels about WebRTC at conferences:
    http://www.youtube.com/results?search_query=Cullen+Jennings

    Cisco wants to sell products to the enterprises and telcos. More HD-video also means more opportunities to sell new networking devices (switches, routers) and support.

    Maybe Cisco want to get on the market quickly with some kind of VoIP gateway and multi-point teleconference products or extend an existing UC-products. I’m sure they have some highly optimized H.264 encoder/decoder (hardware ?), do they have a solution that is as much optimized for VP8 as well ?

    To be honest I think they wanted to deploy VP8 to:
    http://www.youtube.com/watch?v=Lxg-yvYsT1E#t=1m00s
    http://www.youtube.com/user/Cisco/search?query=webrtc

    My guess is, at some point people just want to get product in the market. The Mokia/VP8 patent case would probably just take to long.

    The source code is useful, because if they have a proper open source project many developers can work on the code. Of which Cisco can put build new binaries and put them on their download site.

    And no Cisco won’t be covering you if you compile it yourself, they can’t do that isn’t how these patent licenses work. I’m sure they would have liked an easier solution, but they can’t.

    They can only make it available as a binary and every user needs to download it themselves (the software they are running will probably do it for them automatically).

    As Cisco is paying the license, they need to be the one that is distributing it to the users.

    The amount of money companies need to pay for the patent license is capped, so people have been speculating Cisco might already be paying the maximum or is close to it.

    • I assume it is about supporting Cisco’s own legacy. Migrating it all to support VP8 is probably too much of an understaking and paying the missing amount to meet the cap of MPEG-LA was a lot cheaper.

      My concern is the roadmap of H.265 and VP9 here. This is what gets compromised with this move.

  2. An additional question to add to your list: What does this imply for hardware support of VPx? One of the things lacking about VP8 was direct support for it’s use in silicon, which could be critical to battery life in mobile devices. There was always rumor that it was just around the corner.

  3. as I noted in my blog, I don’t see Apple and Nokia devices supporting VPx in hardware anytime soon.

    https://www.nemertes.com/blog/did-cisco-solve-webrtc-video-codec-problem

    • True. Though one may argue that not all H.264 implementations on chipsets, hardware and phones can do anything good with real time video communications. And to that point, in some cases, the access to the codec itself is either non existent or limited by the OS itself.

  4. You are being unfair to Cisco with your “non-player in WebRTC” ad-hominen slight. As Lennie says, Cullen Jennings and others are highly active in the standards bodies and Cisco is out in the market proactively talking about WebRTC. It is quite normal for Cisco, and large companies like them, to watch an early market and wait and not be active with products until they decide how they want to play and then arrive in force. “Business” as usual, no surprise. (So credit to Oracle Communications, fka Acme, who seem to be been the most proactive large vendor so-far with concrete product announcements). This Cisco’s H.264 announcement is itself a clear indication of lots of internal action and decision-making within Cisco – they have got a multi-million dollar budget to support this, support all the way up to @rowantrollope, and negotiated with Mozilla, all in time for the IETF meeting. Clearly Cisco believes that H.264 as the WebRTC MTI video codec is in their best interests – and no surprise, they have entire portfolios of H.264 based products that will be easier to integrate and they don’t want to be forced to support Google-originated stuff. And to be fair to Cisco again, I think what they did announce is probably the best “most open” they could manage given all the licensing and legal issues around MPEG LA and H.264. It must have been clear to them that VP8 would win the status-quo because of the H.264 licensing issues, so they have tilted the table back towards H.264 as far as they conceivably could. We shall see what this does in the IETF decision-making.

    I also think that Cisco is laying down a challenge to Apple and Microsoft to do the same on their platforms – make H.264 “free” on their platforms to not only their own apps but to any developer, encode and decode, through WebRTC APIs.

    • I guess that non player was a tad overdone. And yes, this is the best you can get with H.264.

      Question is – once you hit the horizon and need to switch to the next gen codec – which road do you take?

      • Well the decision at the next MTI fork in the road will be strongly influenced by this one, which is why the H.264 vs VP8 or both battle right now is so critical for vendors and worth Cisco’s $65M/10-years or whatever :). VP8-only now would make VP9 the strongest next step, while H.264 now leaves things a bit more open as vendors regroup. Google would obviously get back to pushing VP9, Mozilla seems to believe that a future Daala would be the next leap (and Cisco has some limited engagement in this), and H.265 would be there but with even worse licensing complexities, so who can tell at this point?

  5. A lot of the discussion here and elsewhere is about how benevolent or evil Cisco is as a result of this startling announcement. My view is that they have done the best currently possible under the complex MPEG LA licensing constraints to make H.264 as open as possible – regardless of where I fall on the best MTI decision. But why is this all about Cisco? The elephant in the room is Apple – they are the ones who are not providing APIs to their own embedded hardware accelerated H.264 code, not offering MPEG LA licensing coverage as Cisco is now doing, not allowing add-on binaries to be downloaded into iOS so Cisco’s benevolence can be added, making it pretty difficult for other browsers to exist in iOS with all their pieces, and not yet indicating any planned support for WebRTC within Safari. Apple is the vendor making open cross-platform WebRTC difficult. They need to step up.

    Microsoft is obviously another vendor to question next, but let me focus on MPEG LA. This is where the H.264 encumbrance issues could be fully solved by having this now old H.264 codec become royalty free, at least for Internet use. Cullen Jennings (here: http://bit.ly/16TJ5R1) suggests that this is something Cisco would like to see, but obviously all of the patent pool members have to agree and this will be very political and complicated. Some of them, Nokia (aka Microsoft now) in particular, are still busy suing Google to try and damage the openness of VP8, so obviously more pressure is needed on these members (I’m doing my bit in my phone choices).

    So let’s put pressure on Apple, Microsoft/Nokia, MPEG LA and others to get on the Open Web train and allow H.264 video to be easy and pervasive across the Internet and mobile world, rather than simply focusing on why Cisco hasn’t achieved enough all by itself (huge though it is). Alternatively, the IETF goes with VP8 as the sole video MTI codec foe WebRTC, but I don’t know that I see this happening now (it was the obvious right answer last week…)

Trackbacks

  1. […] Tsahi Levent-Levi wrote that this isn’t just about H.264 and VP8, but H.265 and VP9 as well. He pointed out that if H.264 becomes the standard, it effectively guarantees H.265 as its successor. This diminishes Cullen Jennings’ point about H.264 patents expiring. The question was from an analyst on a conference call asking how long Cisco would bear the costs of distributing H.264, and Cullen broadly mentioned that H.264 is old, and its patent protections will eventually expire. That’s true, but with H.265 we are back to where we started. […]

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="">