The WebRTC Codec Conundrum
As someone who has spent most of his career in the Voice over IP industry, I’ve come to recognize the seasonable resurgence of voice and video codec discussions. Like the cicadas that emerge from the earth every few years and raise a racket with their mating songs, developers of real-time communications applications manage to band together every so often and remind us about the ever-changing codec choices and complain (loudly) about the licensing fee issues associated with them.
These last few weeks, it’s been the WebRTC developer community that has issued a flurry of blog posts about new codecs, new alliances and new vendor commitments:
Tsahi Levent-Levi, a prolific advocate for WebRTC, wrote in his BlogGeek.me blog recently about the recent resurgence of the “codec wars”, essentially the battle between advocates of various video codecs, driven by the ever-changing codec landscape, the result of new innovations, and corporate philosophy to “the better good." Tsahi also puts a spotlight on a much-needed effort to find the Holy Grail for WebRTC developers – an efficient and royalty-free video codec, and the launch of the Alliance for Open Media http://aomedia.org/ The alliance is a consortium of major web and technology companies that are “focused on developing next-generation media formats, codecs, and technologies in the public interest”.
Earlier this month, Chris “Kranky” Koehncke weighed in with “Codecs and what you should know” - sobering thoughts on video codecs, how they come to be, and the business behind bringing them to market. His post reminds us that corporations spend a lot of time and money on the development of codecs, and at some point, they would like to earn some of that investment back. Without the promise of a return (either direct or indirect), there will be no investment. Chris also points out that many of the techniques used to compress voice and video were long ago patented and those that own the patents have very different goals from the community that wants to use them.
What’s the lesson here for developers?
- Codecs are an ever-changing – getting better, more efficient and hopefully, less expensive. Get used to it.
- Assume that the codec you are using today will not be the same you will be using next year (or the year after).
- When building an application, developers would be wise to give serious thought to selecting the underlying technologies – ensuring they are able to quickly adopt new codecs while continuing to support older codecs.
- Most applications will need to support new and old codecs simultaneously – needing to support various browsers and mobile devices. History has shown that old codecs die slowly. Heck, we still support fax!
- Avoid being “locked in” to any platform or technology that will be difficult or slow to support new innovative codecs.
Recognizing these needs is core to the Dialogic PowerMedia XMS product strategy – delivering a platform to developers that makes it possible for them to create new services, without having to worry about the specifics of codecs. Using standards-based APIs, developers can use abstract API commands to build applications and leave the dirty codec work to the media server. Whether it’s video streaming, conferencing, transrating, or transcoding, the media server does the heavy lifting.
In the end, the application developer should rise above the “codec wars,” ignore the call of cicadas, and focus on their application along with the business opportunities that it creates.
About the Author
Alan Percy, Senior Director, Product Marketing, Dialogic, is responsible for the global marketing efforts to nurture the growing community of real-time communications and WebRTC applications developers with the rich media processing solutions from Dialogic.
You can have an opportunity to speak with Alan in person at ITEXPO Anaheim, October 5-8, where he will be participating in two session: Why WebRTC will Improve Customer Experience and Open Source in the Service Provider Network. And, you can share your thoughts with Alan on Twitter @AlanDPercy.
Edited by Peter Bernstein