Open-Sourced H.264 Removes Barriers to WebRTC

Great news from Cisco: Cisco will open open-source their H.264 codec, and make H.264 free for use in WebRTC.

Here are the details, which came from blogs of Cisco by Rowan Trollope:
When it comes to making collaboration technology such as high-definition video open and broadly available, it’s clear that the web browser plays an important role. The question is, how do you enable real-time video natively on the Web? It’s a question that folks are anxious to have answered.

WebRTC–a set of enhancements to HTML5–will address the issue head on. But, there is an important hurdle that must first be cleared, and that’s standardizing on a common video codec for real-time communications on the web – something the Internet Engineering Task Force (IETF) will decide next week.

The industry has been divided on the choice of a common video codec for some time, namely because the industry standard–H.264–requires royalty payments to MPEG LA. Today, I am pleased to announce Cisco is making a bold move to take concerns about these payments off the table.

We plan to open-source our H.264 codec, and to provide it as a binary module that can be downloaded for free from the Internet. Cisco 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 in WebRTC.

I’m also pleased that Mozilla has announced it will enable Firefox to utilize this module, bringing real-time H.264 support to their browser.

“It hasn’t been easy, but Mozilla has helped to lead the industry toward interoperable video on the Web,” said Brendan Eich, Mozilla Chief Technology Officer. “Cisco’s announcement helps us support H.264 in Firefox on most operating systems, and in downstream and other open source distributions using the Cisco H.264 binary module. We are excited to work with Cisco on advancing the state of interoperable Web video.”

Why is Cisco Doing This?

Many, including Cisco, have been backing H.264, the industry standard which today powers much of the video on the Internet. We strongly believe that interoperability is an essential goal of standards activities and that usage of H.264 by WebRTC means it will be able to interconnect, without transcoding, to a large set of existing clients from a multitude of vendors.

Regarding H.264, Jan Färjh, Vice President, Head of Standardization and Industry at Ericsson, states: “Support in WebRTC for H.264 enables interoperability with most video-capable mobile devices, which is great for industry acceptance.”

Finally, if you’ve read my blog or attended our recent annual Collaboration Summit, you will have heard our mission for Cisco Collaboration: Create rich collaboration technologies that are incredibly easy to use and make that technology broadly available to everyone in the world – from the largest companies to the smallest businesses. That’s what we would like to see happen with WebRTC, powered by an industry standard that is already prevalent in the market place.

We hope and believe that this step of open-sourcing our H.264 codec will enable the industry to move forward on WebRTC and have the best of all worlds: interoperability with the large installed base of H.264 endpoints, combined with an open‐source and effectively free codebase. This action also underscores our commitment to simplicity, for the greater benefit of developers, users, and vendors alike.

I’d love to start a dialogue on this which is why I’m inviting you to attend a TweetChat I’m hosting (@rowantrollope) later today, Wednesday, October 30 at 9:30 a.m. PDT. The hashtag is #collabchat. Cisco Fellow Cullen Jennings (@cfluffy), Cisco Collaboration CTO Jonathan Rosenberg (@jdrosen2) and Snorre Kjesbu (@KjesbuSnorre), Vice-President of Cisco’s Collaboration Endpoint Technology Group, will join me in the conversation. I also welcome your comments on this blog.

October 2013:Reputation comes from the company you keep

In the past weeks, I was busy working on my new assignment: H323 protocol stack.
After about two monthes hard working, I can finally say that I almost made it, which means I can figure out the reasons of most of the remained bugs/defects, and can resolve them in time if it is protocol relevant. And, I’d say that it’s really a tough one, gaven the backgroud that all the team memenbers had left Kedacom, I have no one to turn to.

However, lots of mistaken/jokes happened during this period.

One biggest mistake/joke was, I said in a weekly meeting, right in front of all the team members, that doing write operations to an NULL pointer can make the app’s top sections of memory (BSS) wrong…

This brief came from an existing code of H323 stack, which apprearantly wrong:


if ( NULL == m_ptMsgDelay )
memset(m_ptMsgDelay, 0, sizeof(m_ptMsgDelay));


I declared it wrong when I first saw line 1:”if ( NULL == m_ptMsgDelay )”.
But I did no more dug on the further codes, because I had tons of codes to read, and I didn’t want to be stucked in some particular lines of code.

When the weekly meeting came, and I didn’t know what to say about, I remenbered this issue, so I brought it out, saying it could lead to write wrong data to an invalid memory section.

Being a programmer for over 10 years, I’ve handled with hundreds of NULL pointer issues. Saying words like this, it’s really out of sense. Even now, I do not know what I was thinking, what I was saying about.

So, yes, I lost all my reputations before gain it. I think this could be a tremendous joke in the whole team, and can be joked all around the company.

Like it or not, it could be a life-time mark for myself. I can also remenber it by joking it around like it or not.

Two lessons:
1. When you see something suspicous, try dig it out.
2. Let it be, if you dont have things to say about.

The good thing is, having nothing valuable to look back, I can look forward now.

20131108 update:

I brought out the codes which I’d made mistake, In the last week’s weekly meeting, to joke how a programmer with over ten years of experience could make such a fault on a knowledge of basis.
But, after a few minutes check & review, I was astonished. Most of the team members were also wrong about the common senses.

So, today, I decide to put it here on my blog, if you happen to see this article, make a test for yourself. If this is the code you need to review, how would you think of it?

typedef struct tagMsgDelay
s32 nMesgType;
s32 nSubReq;
s32 nDelayTime;
u32 nReserved;

TProxyMsg* m_ptMsgType[MAX_MSG_QUEUE];

void InitProxyClient() {
if ( NULL == m_ptMsgDelay )
memset(m_ptMsgDelay, 0, sizeof(m_ptMsgDelay));

Key point of this code:
1. if ( NULL == m_ptMsgDelay )
2. memset
3. sizeof(m_ptMsgDelay)
4. sizeof(NULL)

RTSPPlayer update: Supports hardware decode and render the video with OpenGL ES

The old version of RTSPPlayer was using ffmpeg + SurfaceView + RGB565 mode to decode and render the video. However this implement is definitely a sucked one, especially when watch high quality videos.

So I made some change for it.
And the new solution is HW decode + GLSurfaceView + YUV420P, which can take advantage of the GPU, and improve the performance by these facts:
1. Dont need to convert color space from YUV420P to RGB565 by CPU.
2. Dont need to diliver the huge image buffer from JNI to Java.
3. The render performance can also be significantly improved.

By my simple tests, it SHOULD work on most of the Android OS and phones. Watching a 720P, even 1080P video will no longer be tough for your phone. Wish you’d like it.

You can download the new release from here: