Libwebrtc does not include support for H264 by default. While the code could support it, there are legal obligation when it comes to compile and distribute H.264 in your product: License and royalties! CoSMo just contributed a patch to make libwebrtc use OpenH264 (free as freedom) for encoding, and to dynamically load the Cisco provided library to make it free (free like beer).

Historically, Firefox has had support for H.264 before chrome, even those the first available H.264 patch from Kaiduan XIE, a chinese born Canadia then working for RIM/BlackBerry, was against libwebrtc. The first implementations where symmetric, i.e. the encoder and decoder were using the same library.

Chrome had used ffmpeg, likely with license, for long time for playback of H.264 in the video element. They had spent a lot of time to integrate it, clean it, and secure it. The decision was then taken to use cisco provide openH264 for encoding, and ffmpeg for decoding. Two years after the first patch by K.X., H.264 support landed in chrome.

While google might have a license for it, most devs using libwebrtc did not. The H.264 supports, and its legal consequence was then put behind a configuration flags to make sure that no individual could claim adding H.264 by accident.

ffmpeg_branding = "Chrome"
rtc_use_h264 = true

Nowadays, many sites, and products, are using those GN flags, often oblivious to the legal implications. If you compile and distribute the result of this compilation, you owe money to MPEG-LA.

During the infamous “codec war”, within the standardisation process of WebRTC, to make things simple, and remove the royalty problem from the table, Cisco provided pre-compiled version of openH264. Cisco having reach the cap of the license, they would not pay more by doing this. It did not solve all problems, first because people like to complain, then because it would work for mobile, and wouldn’t;t cover a few other corner cases. However, for desktop software, it was a good thing.

Mozilla then implemented an extension of libwebrtc to be able to use this library, on demand. It would download it on demand (not to distribute it), and use it pre-compiled (not to compile it), and by doing those two things, it would prevent being legally bound to any H264 license. The process in place to achieve this feast is very tied to firefox specific multi-process architecture and could not be ported back to the official, upstream, libwebrtc. Moreover, Firefox is always a few versions behind, so the code would need to be ported first.

CoSMo is being asked very often to provide libwebrtc builds with H.264 supports, even in the community builds (free as beer). Taking the available approach it would make us liable for all the usage our customer would have. Best case scenario, our customer would be shouldering the royalties, but would have to put into place a specific accounting process to know how many H.264 units where shipped. Less than Ideal.

With the new patch, cosmo is contributing back to libwebrtc the same approach than Mozilla took. Admittedly Mozilla approach is more complicated because they have a multi-process environment, while libwebrtc stand alone is only multi-threaded, but the main goal: not being liable is equally achieved.

We hope that this patch will be accepted, or help many companies to add (software) H.264 support in their product, without legal implication, in the future.