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. 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:

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:

• Janko Roettgers summarizes the viewpoints of Cisco, Mozilla and Google nicely on GigaOm
• Monti Montgomery explains Mozilla's decisions in joining forces with Cisco
• Dave Michels' view on this and his estimate that H.264 will be the winner here on Talking Pointz
• Gustavo Garcia Bernando writes on OpenTok's blog that they are not taking sides but will benefit from H.264
• Chad Hart gives a detailed overview of Cisco's decision and its effects at webrtcHacks
• Chris Kranky with his unique voice makes the link between Cisco's move and free drug samples